Case-sensitive look up on allowed headers map
EmmEff opened this issue · 4 comments
Allowed headers are ingested correctly in initialization and in the call cors.handlePreflght():
Line 368 in 3d336ea
The headers in the request are handled AS IS.
Allowed headers are normalized during initialization:
Line 199 in 3d336ea
In the function SortedSet.Subsumes(), a case-sensitive lookup is done on the map:
Line 76 in 3d336ea
This issue surfaced in the v1.11.0 release.
The spec says headers are sent as a ordered lowercase list. Is there a specific case where this change break something?
Well it broke my code :)
In my investigation, I was following the docs @ https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS which uses mixed case values in the CSV argument to Access-Control-Request-Headers in their examples.
I see the spec is conflicts with that (as you mention)
@EmmEff The middleware is working as expected. That v1.11.0 broke your code/tests is unfortunate, but your tests arguably shouldn't be coupled so strongly to the intricacies of rs/cors's implementation. I'd be interested to see the failing test in question.
I was following the docs @ https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS which uses mixed case values in the CSV argument to Access-Control-Request-Headers in their examples.
Indeed; for instance,
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
should read
Access-Control-Request-Headers: content-type,x-pingother
Well spotted; I understand how that can trip people up. In that case, the right thing to do is open an issue on https://github.com/mdn/content; I'll do that.