Closed dosmanak closed 8 years ago
It's not a problem to implement this; however, doing so will restrict VRC to services that accept GET request body (like ElasticSearch) while other services may not accept that according to RFC.
It's pretty straightforward to fork this project to customize it for ElasticSearch. For now, I use POST in place of GET to include the request body for ElasticSearch.
You are right it is against the RFC. The customization is also easy. But I thought perhaps some configuration option would be more user friendly than maintaining the fork.
It seems to be a feasible option. I'll try that.
FWIW, it is not against the RFC : http://stackoverflow.com/a/15656853 which is why ES uses it, see the first note in https://www.elastic.co/guide/en/elasticsearch/guide/current/_empty_search.html .
Yeah, I was vague by "according to RFC." To clarify, it's not against RFC; it's only because RFC doesn't ask that the service must accept the body.
Actually, the initial plan was to support GET params specified in the request body
, and when VRC executes cUrl, it would pass those as GET params to cUrl (using --data-urlencode
instead of --data
). However, I've noticed it doesn't work correctly unless VRC allows parsing the request body
line by line.
Anyway, I've already had a plan to support GET request body.
GET request can now have request body using the new option vrc_allow_get_request_body
.
Great, thanks!
If body defined with GET methon, it is not send. But elasticsearch uses it.
curl can post data to GET.
https://www.elastic.co/guide/en/elasticsearch/reference/1.6/search-request-body.html
Can you implement this? Thanks