Added in basic CORS support.

[far-blue]

I've added a list of headers the proxy should allow to pass through so a server can respond to CORS requests. I've also made the proxy auto-respond to OPTIONS requests with a basic, pretty permissive CORS reply.

This won't support situations where the proxied server wishes to customise the OPTIONS reply.

Could do with something to allow customisation of allowed headers though.

[veggiemonk]

Really nice!! Thanks

[mathroc]

I'm not sure it's a good idea to auto respond to OPTIONS request, shouldn't it be the responsibility of the application server to handle that ?
additionally, the proxy_pass_header directives are not needed, those headers are already authorized.

you can reproduce my test with this gist: https://gist.github.com/mathroc/5b2bb374854878511d9a

[far-blue]

I agree that it should be the responsibility of the application server to handle the request. However, my analysis using tcpdump shows that OPTIONS requests are converted to GET requests when proxied (which is a Bad Thing) and I couldn't find a way around it.

My pull request is only suitable for a dev environment where there is no requirement to control the result of the OPTIONS preflight. As for the proxy_pass headers, I agree but it makes the intention of the configuration explicit.

As I also note, the pull request makes no allowances for additional allowed headers. Really, the pull request is a starting point and certainly needs more work but it's better than we had before :)

[mathroc]

well, I've upgraded the gist to show print the http method, and use this curl call to test it : curl -v -X OPTIONS http://test-jwilder-nginx-proxy.127.0.0.1.xip.io/

in my case it's not converted to a GET request:

*   Trying 127.0.0.1...
* Connected to test-jwilder-nginx-proxy.127.0.0.1.xip.io (127.0.0.1) port 80 (#0)
> OPTIONS / HTTP/1.1
> Host: test-jwilder-nginx-proxy.127.0.0.1.xip.io
> User-Agent: curl/7.42.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: nginx/1.9.0
< Date: Sun, 21 Jun 2015 21:39:33 GMT
< Content-Type: text/html; charset=UTF-8
< Content-Length: 20
< Connection: keep-alive
< X-Powered-By: PHP/5.6.10
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, DELETE
< Access-Control-Allow-Credentials: true
< Access-Control-Allow-Headers: Origin,Content-Type,Accept
< 
string(7) "OPTIONS"
* Connection #0 to host test-jwilder-nginx-proxy.127.0.0.1.xip.io left intact

can you explain how to reproduce your observations ?

[far-blue]

My observations come from switching a dev setup that works correctly without the proxy in the middle and then debugging the problem which, as I say, was due to OPTIONS requests being passed through as GET requests.

My setup is an apache 2.4 server in a container linked to a php5.5 fpm container on tcp port 9000. The apache container is being proxied by the nginx-proxy container. The client requests are coming from jQuery. Because the requests are for json data the accept header is for json.

I debugged the issue by tcpdump'ing the data flow in and out of the proxy container and it is easy enough to see the incoming preflight OPTIONS request being converted into a GET request as it is passed on to apache and then seeing the real GET request coming in afterwards. Because I'm seeing the traffic in and out of the proxy I've discounted any issue between apache and fpm. Because I know it works correctly (apache / php respond to the OPTIONS preflight correctly) when the proxy isn't in the middle my deduction is that the proxy is the piece changing the OPTIONS to a GET.

As your tests don't show this behaviour I'd guess it has something to do with which headers are passed - e.g. changing the Accept header.

[jwilder]

This is better to be handed by a custom template by the user than having it in the default image.

[md5]

Unlike when this PR was created, I think it's now possible to achieve an equivalent setup by extending this image with the /etc/nginx/proxy.conf and /etc/nginx/vhost.d/default_location files.