jub0bs

Here is a (failing) test case that illustrates the issue: ```go func TestHandlePreflightLowercaseAllowedMethod(t *testing.T) { const ( origin = "https://foo.com" method = "patch" ) s := New(Options{ AllowedOrigins: []string{origin}, AllowedMethods:...

Related: https://github.com/rs/cors/issues/157

@creativecreature What you're suggesting isn't as simple as it seems. For instance, would/should the following work? ```go type Point struct { Y, X int } type Rect struct { X,...

@creativecreature Isn't this the same code snippet as in your earlier comment? I don't think we're going to make much progress in this discussion if you answer my simple question...

@atdiar Both methods _and_ fields get promoted from the embedded type to the outer struct; see https://go.dev/play/p/64XgN0ucshE

Here is one source of inspiration: https://github.com/jub0bs/cors @empijei Middleware produced by my library let non-CORS requests through (as it should).

@ChronosMasterOfAllTime FWIW, [my CORS library](https://github.com/jub0bs/cors) supports multiple `Access-Control-Request-Headers` headers out of the box and in a more efficient manner. See https://github.com/jub0bs/cors-examples/blob/main/chi-v5/main.go for an example of how to use it with...

No worries. You may enjoy this recent post of mine: https://jub0bs.com/posts/2025-04-30-inlinability-challenge/

> Maybe if something like https://wicg.github.io/cors-rfc1918/ motivated adding such complexity to navigation this would become more feasible. But until that happens this isn't worth the significant cost unfortunately. It's worth...

The proposed change is a breaking one (in terms of behaviour), but I don't expect that many CORS-aware servers wish to allow clients to send _actual_ `OPTIONS` requests.