OPTIONS requests succeed preflight, fail actual

[aiwilliams]

I have spent a significant amount of time trying to resolve a situation where for an OPTIONS request, the preflight looks perfect but the actual request is considered an error by the browser. It turns out that the reason is that there is no Access-Control-Allow-Origin: * header in the actual request response. When I added it to the response, things work great!

Consider the current behavior:

  if env['HTTP_ORIGIN']
    if env['REQUEST_METHOD'] == 'OPTIONS'
      if headers = process_preflight(env)
        return [200, headers, []]
      end
    else
      cors_headers = process_cors(env)
    end
  end

The REQUEST_METHOD is "OPTIONS" on the actual request, but is not a preflight. Therefore, no cors_headers will be present. As I understand it, the Resource Processing Model indicates that it would be correct to "add a single Access-Control-Allow-Origin header, with either the value of the Origin header or the string "*" as value" as step three of any of "Simple Cross-Origin Request, Actual Request, and Redirects" server response.

I would like to fix this immediately if @cyu agrees with this analysis. If there is disagreement, I would like some interaction about why I cannot make an OPTIONS request. I believe this is related to #24.

[cyu]

Yep, you're correct. I'll accept PR for this if you have one. Otherwise, I'll try to get this in as soon as I can.

This doesn't specifically cover #24 - this section specifically states to abort CORS processing if Origin isn't set: http://www.w3.org/TR/access-control/#resource-requests.

[cyu]

Fixed in 910f6df