Content type is incorrectly set (breaks request body searches via elasticsearch-transport-wares servlet)

[tstibbs]

In my system http is disabled on every elasticsearch node. The only way to access the rest interface is via a webapp which uses the elasticsearch-transport-wares servlet to expose the rest interface. This way, I can lock down access to the rest interface using traditional j2ee authentication.

When I do a request body search using head, it sends a POST with json as the body, but doesn't set the content type - so jquery defaults it to application/x-www-form-urlencoded; charset=UTF-8. This is incorrect, it presumably should be application/json.

This causes an issue because tomcat (I haven't tested other web containers yet) drops the body because it isn't form encoded, so when elasticsearch tries to decode the body, there's no body for it to use. Thus, all searches end up being treated as empty, which elasticsearch assumes means 'match_all'.

[tstibbs]

Just noticed #71 - if there's a problem with CORS stuff, maybe there needs to be some kind of switch somewhere (a tick box which says "j2ee container compatibility mode" or similar)?

[mobz]

yeah - I'd consider some kind of switch. I have a plan to create a connect panel, to allow setting more options. Consider opening a feature request on elasticsearch to support the correct CORS header, alternatively you might be able to modify the requests using some kind of proxy, or you could create a fork of head which contains just the changes from #71

[tstibbs]

We were expecting to fork it, which is ok, the change is pretty small.

However just wondering if ES isn't already sending the correct headers? See elastic/elasticsearch@f659cad#diff-c6b7411fc7a3472b754ce9ea85e49448, it looks like it should respond to the browser's pre-flight 'options' request with content-type being an allowed header. When I make an options request it sends back something sensible looking:

Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: X-Requested-With, Content-Type, Content-Length

Was there a problem with older browsers not doing the options request properly or was the version you were testing on just older (0.20.0 appears to contain that fix)?

[mobz]

That commit is a good find. Since we can't work out the version of elasticsearch without a request (which will fail), the best way to handle backwards compatibility is to attempt to catch the failed request, and retry without the content-type? (for reasons that are too annoying to mention, I want to keep head mostly compatible back to 0.19) Testing this fix is going to be a pita :(

[tstibbs]

I've put something together for this, see #110. Seems to work cross origin and I've tested it with an elasticsearch 0.19.0 instance on another host and all seems to work ok.

My code probably isn't that elegant, I'm no javascript dev, there's probably a better way of detecting the error.

[mobz]

closed by #110