jub0bs
jub0bs
@kilgaloon Any further comment? Can we close this issue?
@rs Without feedback from the OP, and in light of a [recent comment of yours](https://github.com/rs/cors/issues/184#issuecomment-2307247534), I'm inclined to reject this suggestion.
@stonedu1011 This is working as expected. In addition to #176, see #180 and #181. TL;DR: According to the Fetch standard, the `Access-Control-Request-Headers` header only ever contains lowercase values; this library...
@stonedu1011 Can we close this issue?
@rs Without feedback from the OP, I'm inclined to close this.
@mitar > I was also hit by this and had to spend an hour now debugging why upgrading this library is breaking tests. [...] This has now been reported few...
> this might be much easier with some changelog entry or README entry or something I strongly agree: rs/cors does need a changelog; feel free (if time allows) to open...
Thanks for the additional context. > I think using the following to convert string into []byte in-place That requires the `unsafe` package, though. I don't know about @rs, but I...
> An alternative way may be to have both lowercase and mime-case versions of allowed headers in the allow set with equal position value? If case insensitivity is the goal,...
@rs > What do you think? If you're asking me, I think case sensitivity in ACRH should be maintained, for reasons explained in [an earlier comment](https://github.com/rs/cors/issues/183#issuecomment-2346862159). As far as [jub0bs/cors](https://github.com/jub0bs/cors)...