High Level Rest client should use POST when we have body

[dadoonet]

When elasticsearch is behind a Proxy and this Proxy does not support GET with body (which might be seen as a bug of the Proxy), people can't use our Java Rest Client as explained in https://discuss.elastic.co/t/es-cluster-via-proxy-ip-but-listener-timeout-after-waiting-for-30000-ms/116192/6

For example, the search Request here uses a GET method:

elasticsearch/client/rest-high-level/src/main/java/org/elasticsearch/client/Request.java

Line 424 in b98514c

return new Request(HttpGet.METHOD_NAME, endpoint, params.getParams(), entity);

I think we should may be switch to POST instead anytime we might have a body.

Thoughts?

[javanna]

Makes sense. What I had in mind was to have an option that lets you choose between GET and POST, like other language clients do. Or switching to POST like you proposed.

[DaveCTurner]

The use of bodies in HTTP GET requests is a little unusual. Although the spec is not crystal clear on the subject, it is possible to read it in a way that means the body of a GET request can and should be ignored: https://stackoverflow.com/a/983458

[javanna]

@DaveCTurner I don't think this is the right place to discuss what our API should support. Our API supports both, we always had a preference for GET with body but we decided (years ago) to support POST too for clients and proxies that don't support GET with body. In our clients, we should follow what the API exposes, hence we should allow to choose between POST and GET if the API allows both. This is something that I had wondered about when going for GET only but I was waiting for the first user to point out that GET causes trouble to them.

[DaveCTurner]

Sorry, I didn't mean to open that debate. Supporting both on the API side seems fine. Just wanted to say that a proxy that doesn't pass the body through on a GET request shouldn't necessarily be considered buggy - it is more of a bug in the spec itself that this difference of opinion can exist. Using POST seems safer in situations that might involve a proxy: not only will it fix the OP's problem but it'll also avoid the possibility that the response is cached and quietly re-used in response to different queries against the same URL.

What'd be the disadvantage of completely switching to POST in the client as @dadoonet suggests?

[jasontedor]

Completely switching to POST for requests with bodies from the client seems like the right approach to me. Since we support both POST in all such cases there's no need for the additional complexity of a toggle?

[Mpdreamz]

All low level clients either allow you to either pass any HTTP method or expose all the API + allowed http method combinations.

Defaulting to POST for high level clients and not making this configurable makes sense though, it's also the approach the high level c# client NEST takes.

In some cases NEST is smart enough to revert back to a GET automatically e.g if only the query on the querystring (?q=) is provided on _search or if the source common parameter is provided. This is not really standardized though.

[javanna]

Cool thanks for the feedback let's do POST only then. I prefer one less configuration knob too.