I am no expert on HTTP CORS myself (hardly a beginner), but my
interpretation from reading this: https://developer.mozilla.org/en/http_access_control#Preflighted_requests
(see end of the section), is that if elasticsearch return these
Access-Control-Allow-Methods: POST, GET, PUT, DELETE, OPTIONS
then it should work (since a POST request with content-
type:application/json is preflighted, and the response header is
checked for allowed methods). It would be great if someone with
knowledge of http cors can shed more light on this and propose a more
generic and encompassing change to elastic search headers.
On Apr 7, 8:38 am, Shay Banon kim...@gmail.com wrote:
It would be great if someone could chase down what needs to be returned
into order to support this, so there won't be a need to configure it
(unless you want to disable it completely). Seems like the spec has changed
since last I read it, and it might be different between browsers.
On Fri, Apr 6, 2012 at 1:29 AM, Anurag Biyani abiy...@dnanexus.com wrote:
I am unable to make an ajax query (POST with contentType: "application/
json") to elasticsearch server from google-chrome, because elastic
search seem to return this in response header by default
thus following error is generated:
XMLHttpRequest cannot loadhttp://localhost:9200/_search. Request
header field Content-Type is not allowed by Access-Control-Allow-
This is similar to issue described here:
, I was wondering if there is any way now to configure Acess-Control-*
headers returned by elastic search.