CORS OPTIONS requests not supported, breaking usage with SPDY

[Thomas Bachem]

When enabled SPDY support in nginx, Chrome sends an OPTIONS request to e.g. /progress first, before requesting it via GET.

This results in a 405 Method Not Allowed response right now:

Request URL: https://example.com/progress
Request Method: OPTIONS
Status Code: 405 OK

Request Headers:
accept:/
accept-encoding:gzip,deflate,sdch
accept-language:de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
access-control-request-headers:accept, origin, x-progress-id, x-requested-with, content-type
access-control-request-method:GET
host:example.com
method:OPTIONS
origin:http://example.com
referer:http://example.com/
scheme:https
url:/progress
user-agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.81 Safari/537.36
version:HTTP/1.1

Response Headers
content-length:568
content-type:text/html
date:Mon, 03 Jun 2013 09:04:03 GMT
server:nginx
status:405
version:HTTP/1.1

Instead, something like the following response should be returned by the upload progress module:

Access-Control-Allow-Origin: $request_origin
Access-Control-Allow-Methods: GET, HEAD, OPTIONS
Access-Control-Allow-Headers: $access_control_request_headers
Access-Control-Max-Age: 86400

Possibly somehow related to http://forum.nginx.org/read.php?29,236251,236251.

[Michael Kliewe]

I can confirm that the progress does not work when SPDY is enabled. Please fix it, we would like to enable SPDY!

[Brice Figureau]

Well to my knowledge (didn't try it), the problem is that OPTIONS is not supported by Nginx (nor this plugin).
But I believe this can be worked-around with something like that:

location /progress {
        ...
        if ($request_method = OPTIONS ) {
            add_header Access-Control-Allow-Origin *;
            add_header Access-Control-Allow-Methods "GET, OPTIONS";
            add_header Access-Control-Allow-Headers "origin, authorization, accept";
            add_header Access-Control-Allow-Credentials "true";
            add_header Content-Length 0;
            add_header Content-Type text/plain;
            return 200;
        }
        ...
}

If that's working, please let me know.

I'll see how I can fix this issue in the plugin itself.

[Brice Figureau]

Can someone confirm the above work-around works?

[Chris]

Can someone confirm the above work-around works?

@masterzen No unfortunately it does not..

[Michael Kliewe]

I tried this workaround a few month ago, and it was not working...

[Robert Gründler]

@masterzen fyi: this is working for us:

# upload progress
location ^~ /progress {

  if ($request_method = OPTIONS ) {
    add_header Access-Control-Allow-Origin allowed-host.example.com;
    add_header Access-Control-Allow-Methods "GET, OPTIONS";
    add_header Access-Control-Allow-Headers "origin, authorization, accept, X-Progress-ID";
    add_header Access-Control-Allow-Credentials "true";
    add_header Content-Length 0;
    add_header Content-Type text/plain;
    return 204;
  }

  add_header Access-Control-Allow-Origin allowed-host.example.com;
  add_header 'Access-Control-Allow-Credentials' 'true';

  upload_progress_json_output;
  report_uploads proxied;
}

[fab]

@pulse00 TY for this snippet, this solved problems in the Nginx + Symfony 4.1.x CORS context for me.

I used this snippet inside a specific Nginx location to avoid 405 method not allowed for CORS preflight requests

  if ($request_method = OPTIONS ) {
                add_header Access-Control-Allow-Origin "https://mydomain.ext";
                return 200;
        }