Consul: CORS requests fail with a 405 method not allow for OPTIONS

[v9n]

Hi,

I tried to setup CORS headers:

{
  "http_api_response_headers": {
    "Access-Control-Allow-Origin": "*",
    "Access-Control-Allow-Methods": "POST, GET, OPTIONS, DELETE, PUT"
  }
}

I verified that those headers are return during a XHR request. However, when I tried to do PUT, browser send an OPTIONS request first (http://stackoverflow.com/questions/8153832/xmlhttprequest-changes-post-to-option) and consul return a 405 method not allow.

My request looks like this:

curl 'http://192.168.111.30:8500/v1/kv/lb/extra_hosts/opi' -X OPTIONS -H 'Host: 192.168.111.30:8500' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:39.0) Gecko/20100101 Firefox/39.0' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'DNT: 1' -H 'Origin: http://local.dev:8101' -H 'Access-Control-Request-Method: PUT' -H 'Connection: keep-alive'

and response

So I think the issue comes from consul itself when denied OPTIONS method?

[pearkes]

I think to properly run cross domain with non POST/GET methods, we do need to respond to the OPTIONS preflight request. POST and GET don't send a preflight, and to my knowledge there's no way to skip preflight with headers.

So, we'll need to respond to OPTIONS, basically.

[h2non]

It could be great if the CORS headers could be inferred and settled automatically to avoid issues in browsers. Following the W3C spec this could be done easily based on the existent HTTP request headers.

Probably adding a new Consul config field to enable it would be fine, or alternatively as sort of plugin/addon. The config field could be:

enableFullCORS: true

[teaforthecat]

I'm running into this too. Is there any reason we wouldn't want "enableFullCORS: true" to be default ?

[h2non]

IMO Consul should implement CORS support by default inferring it based on the request HTTP, unless it's explicitly defined that you don't want enable it.

[DarrenN]

This is becoming quite a problem when developing against Consul Agent running locally. The browser app I'm working on cannot make PUTs due to blocked OPTIONS.

[marconi]

same here, it should be able to handle OPTIONS request.

[marconi]

UPDATE: I opened a PR https://github.com/hashicorp/consul/pull/1807, note this is only for kv.

[langston-barrett]

I am also attempting to develop browser application to interact with the Consul HTTP API, and am blocked by this issue. It also effects DELETE requests. Here's what it looks like on the raw HTTP header level:

$ curl -v -X OPTIONS http://localhost:8500/v1/kv/
*   Trying ::1...
* Connected to localhost (::1) port 8500 (#0)
> OPTIONS /v1/kv/ HTTP/1.1
> Host: localhost:8500
> User-Agent: curl/7.48.0
> Accept: */*
> 
< HTTP/1.1 405 Method Not Allowed
< Access-Control-Allow-Origin: *
< Date: Sat, 16 Apr 2016 07:18:42 GMT
< Content-Length: 0
< Content-Type: text/plain; charset=utf-8
< 
* Connection #0 to host localhost left intact

[gmagniez]

Hi,
Same issue with 'v1/event/fire' api endpoint

[Moshem123]

No solution yet? I can't use PUT to update k/v on a web UI I'm building.
Help?

[Yanovskiy]

Any update?

[slackpad]

Now that we support https://www.consul.io/docs/agent/options.html#http_api_response_headers, can we just add generic support for OPTIONS requests and make things work?

[Cosmo439]

Any update on this? It's blocking me on developing an app against the API.

[bersalazar]

Running into this same issue.

[eddsteel]

I'm running my fork and successfully using CORS PUTs to kv endpoints.