CORS Preflight Checks Don't Get Proper Headers

Contribute Bug

AI-generated summary

A CORS preflight check issue is occurring, where the response to an OPTIONS request is missing proper CORS headers. This happens when a DELETE request to the session#destroy endpoint returns a 404 error. CORS is configured correctly, as evidenced by successful calls with proper headers. However, some middleware or stack component appears to be stripping the CORS headers from the 404 response. boushleyExtra notes that eviltrout fixed this issue in commit 963b08f.

1

When trying to make a CORS request that requires a preflight check the response does not contain the proper headers.

Currently I’m trying to implement Single Sign Off and I was told by @sam to use CORS against the session#destory endpoint. When I make a DELETE request CORS does a preflight OPTIONS request. This results in a 404 response that does not have any CORS headers:

content-length:0
content-type:text/html; charset=utf-8
date:Wed, 13 May 2015 17:18:14 GMT
server:nginx
status:404 Not Found
status:404 Not Found
version:HTTP/1.1
x-request-id:f816d011-66c5-4a1b-8b09-6772aa9695c9
x-runtime:0.003151

I know CORS is configured correctly because calls that don’t result in a 404 have the proper headers in place. It appears that some other piece of middleware after the CORS rack middleware is stripping off those headers. The code inside of the CORS middleware appears to be running on these OPTIONS requests, but something else is stripping those headers back off.

Any ideas what middleware or other part of this stack might be sanitizing 404 response headers?

إعجاب واحد (1)
2

Looks like @eviltrout fixed this here 963b08f

إعجابَين (2)