I was playing around with http request to elasticsearch and tried to
rebuild some functionality I usually use the Java API for. One thing I
noticed was that a few examples seem to be not completely conform with the
RFC HTTP 1.1 standard (the way I understand it). For instance get and
delete requests by definition only look at the passed url, not at a passed
entity containing any data. But e.g delete by query or count use that to
transport the query (search is a post request, why not count?).
I know that some implementations (java.net.HttpURLConnection) dont take it
too serious and you still can manage to transport data (some people on the
internet consider this a bug rather than a feature ;-)), but more strict
implementations like Apaches HttpComponents wont do that, so I can not
rebuild these examples in the guide using Apache HttpClient.
I am a bit puzzled here, I admit. Am I understanding something wrong,
should I just simply use post requests instead of get (should work) and
delete (will that work?). Or am I simply the only one who ever came across
this problem?
The RFC does not explicitly forbid sending a body for GET/DELETE. In fact,
it says the server MUST parse any content sent in the body of these
methods. It does however state that it should carry no semantic meaning.
With that said, any client that disallows sending a body for these methods
is technically broken.
To address your question however, you should be able to pass the JSON body
along in the URL via the "source" parameter (e.g., source={...}). Just be
sure to properly escape things. For _search you can simply use a POST (I'm
pretty sure this works). Using a POST instead of DELETE will not work.
On Wednesday, January 23, 2013 9:49:00 AM UTC-5, Andrej Rosenheinrich wrote:
Hi,
I was playing around with http request to elasticsearch and tried to
rebuild some functionality I usually use the Java API for. One thing I
noticed was that a few examples seem to be not completely conform with the
RFC HTTP 1.1 standard (the way I understand it). For instance get and
delete requests by definition only look at the passed url, not at a passed
entity containing any data. But e.g delete by query or count use that to
transport the query (search is a post request, why not count?).
I know that some implementations (java.net.HttpURLConnection) dont take it
too serious and you still can manage to transport data (some people on the
internet consider this a bug rather than a feature ;-)), but more strict
implementations like Apaches HttpComponents wont do that, so I can not
rebuild these examples in the guide using Apache HttpClient.
I am a bit puzzled here, I admit. Am I understanding something wrong,
should I just simply use post requests instead of get (should work) and
delete (will that work?). Or am I simply the only one who ever came across
this problem?
Right, it does not forbid it, RFC states "The DELETE method requests that
the origin server delete the resource identified by the Request-URI." So
actually the passed query should not be considered. Using post instead of
get saves count, but delete by query is still tricky.
Am Mittwoch, 23. Januar 2013 17:29:34 UTC+1 schrieb egaumer:
The RFC does not explicitly forbid sending a body for GET/DELETE. In fact,
it says the server MUST parse any content sent in the body of these
methods. It does however state that it should carry no semantic meaning.
With that said, any client that disallows sending a body for these methods
is technically broken.
To address your question however, you should be able to pass the JSON body
along in the URL via the "source" parameter (e.g., source={...}). Just be
sure to properly escape things. For _search you can simply use a POST (I'm
pretty sure this works). Using a POST instead of DELETE will not work.
On Wednesday, January 23, 2013 9:49:00 AM UTC-5, Andrej Rosenheinrich
wrote:
Hi,
I was playing around with http request to elasticsearch and tried to
rebuild some functionality I usually use the Java API for. One thing I
noticed was that a few examples seem to be not completely conform with the
RFC HTTP 1.1 standard (the way I understand it). For instance get and
delete requests by definition only look at the passed url, not at a passed
entity containing any data. But e.g delete by query or count use that to
transport the query (search is a post request, why not count?).
I know that some implementations (java.net.HttpURLConnection) dont take
it too serious and you still can manage to transport data (some people on
the internet consider this a bug rather than a feature ;-)), but more
strict implementations like Apaches HttpComponents wont do that, so I can
not rebuild these examples in the guide using Apache HttpClient.
I am a bit puzzled here, I admit. Am I understanding something wrong,
should I just simply use post requests instead of get (should work) and
delete (will that work?). Or am I simply the only one who ever came across
this problem?
You could always do a query and get back all the ids for deletion. Then
delete them one by one. Not a very practical approach but it conforms to
the spec better.
Have you tried passing the JSON payload in the URL of a DELETE request?
This might be a feasible workaround especially if your client doesn't
support sending payloads for this particular method.
On Wednesday, January 23, 2013 11:40:35 AM UTC-5, Andrej Rosenheinrich
wrote:
Right, it does not forbid it, RFC states "The DELETE method requests that
the origin server delete the resource identified by the Request-URI." So
actually the passed query should not be considered. Using post instead of
get saves count, but delete by query is still tricky.
Am Mittwoch, 23. Januar 2013 17:29:34 UTC+1 schrieb egaumer:
The RFC does not explicitly forbid sending a body for GET/DELETE. In
fact, it says the server MUST parse any content sent in the body of these
methods. It does however state that it should carry no semantic meaning.
With that said, any client that disallows sending a body for these methods
is technically broken.
To address your question however, you should be able to pass the JSON
body along in the URL via the "source" parameter (e.g., source={...}). Just
be sure to properly escape things. For _search you can simply use a POST
(I'm pretty sure this works). Using a POST instead of DELETE will not work.
On Wednesday, January 23, 2013 9:49:00 AM UTC-5, Andrej Rosenheinrich
wrote:
Hi,
I was playing around with http request to elasticsearch and tried to
rebuild some functionality I usually use the Java API for. One thing I
noticed was that a few examples seem to be not completely conform with the
RFC HTTP 1.1 standard (the way I understand it). For instance get and
delete requests by definition only look at the passed url, not at a passed
entity containing any data. But e.g delete by query or count use that to
transport the query (search is a post request, why not count?).
I know that some implementations (java.net.HttpURLConnection) dont take
it too serious and you still can manage to transport data (some people on
the internet consider this a bug rather than a feature ;-)), but more
strict implementations like Apaches HttpComponents wont do that, so I can
not rebuild these examples in the guide using Apache HttpClient.
I am a bit puzzled here, I admit. Am I understanding something wrong,
should I just simply use post requests instead of get (should work) and
delete (will that work?). Or am I simply the only one who ever came across
this problem?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.