Add CORS headers to non-preflight OPTIONS too #85
Conversation
|
We should probably just not execute the handler on OPTIONS requests with no |
|
I'm not sure why? OPTIONS is used not only in the preflight requests. Fall through is not usable, because the auth is filtered in preflight by browser and on actual request you do not allow it to work with CORS. I would like it to behave as rest of the HTTP methods and while I'm reading the CORS spec, I cannot find a reason why it should be filtered like this and there are actually examples with allowed methods containing OPTIONS. Maybe I'm just misunderstanding something? |
|
Re-reading the spec, I guess you're right. |
|
Please rebase on master to fix the CI. |
Non preflight OPTIONS requests should work with CORS too. This change is removing abort in actual request CORS handler for OPTIONS request, so the client can receive the necessary headers on such request.
|
Done |
|
@rs Is there a possibility to cut a release with this patch included anytime soon? |
|
Done |
|
It looks like the release was done on old tag (v1.4.0) from may 2018, but the latest is (v1.6.0) and new release should have tag > v1.6.0. |
|
fixed |
Non preflight OPTIONS requests should work with CORS too.
This change is removing abort in actual request CORS handler for
OPTIONS request, so the client can receive the necessary headers
on such request.