Question about preflight request behavior.

[cyu]

Question about preflight request behavior.

[cyu]

The CORS spec doesn't specify what the response code should be: http://www.w3.org/TR/cors/#resource-preflight-requests

Having said that, returning 204 does make sense, but doing quick search let me to this bug report in Firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=845881#c4

The comment suggests that returning anything but a 200 is against spec, but I can't seem to find anything in the official spec that confirms that. But reading this issue makes me reluctant to change anything until I can find something official about it.

Regarding the two OPTIONS requests: the first one is not considered a Preflight request (since Access-Control-Request-Method isn't present), and passes the request through to your Rails app which is returning a 204. The second request is a valid Preflight request, which the middleware will process and return without passing the request through to Rails.

As for GitHub's behavior, it is against spec. From the spec:

If there is no Access-Control-Request-Method header or if parsing failed, do not set any additional headers and terminate this set of steps. The request is outside the scope of this specification.

You can read the whole Preflight process here: http://www.w3.org/TR/cors/#resource-preflight-requests. I can only imagine that GitHub does this because it is easy - they probably use a directive at the web server level that just returns that header no matter what.

I have thought about making this optional behavior, but for the sake of keeping the middleware simple I think it should stick to the spec as much as possible. If there's something in the spec that covers these two cases (204 status codes and GitHub's default headers), I'll gladly incorporate them.

[monfresh]

That makes sense, thanks!

While The CORS spec doesn't mention a specific response code, it does explicitly allow any code in the 2xx range.

The Firefox bug you linked to has been fixed, and reading through the comments I get the impression that the final consensus is that 204 is an acceptable, and better code than 200. It was originally against the Firefox spec, not the CORS spec.

I would vote for making Rack::Cors send a 204 instead of a 200 for preflight requests.

[cyu]

Ok, that looks good to me. Yes, I agree that 204 is more appropriate in this case.

[cyu]

Closing this issue and leaving the response status code as 200 since the spec isn't clear. It isn't worth breaking existing behavior.