Thanks for this.
Some reading is required, I'll take a look when I have some time.

@machine424 Great! Let me know if you need some clarification.

Related: rs/cors#10

A different issue is that CORS-preflight response headers like Access-Control-Allow-Headers are included in the response regardless of whether the request is actually a preflight request. The easiest fix for all this would arguably be to rely on a dependable CORS middleware library (e.g. this one 😉).

Hello from the bug-scrub! @machine424 do you think you will get a chance to look at this?

@machine424 I'm here if you need me.

the failing test was fixed on main, rebasing should help.

I see you're very interested in CORS and you did an excellent job with jub0bs/cors!

As you see our CORS setup is really simple (admittedly not flawless though ;)) and I’m personally hesitant to introduce a new dependency just for that.

If we ever need to make more substantial changes into that code in the future, I’d certainly keep jub0bs/cors in mind.

Of course, additional issues are uncovered in the meantime, we may decide to delegate that sooner.

Thanks. That's fair. One obstacle to your adoption of jub0bs/cors is that you seem to support arbitrary origin patterns; my library limits which patterns can be specified (for good reasons).

Meanwhile my two cents, for better transparency/traceability in jub0bs/cors; it'd be great to use PRs rather than directly merging into main (even though you're the only contributor). Also linking those PRs in the changelog would help users better track the changes.

Thanks, I'll take your suggestion into consideration. I'm getting closer to releasing a v1; I can start using PRs then. Whatever happens, I make sure to document, in the changelog, any changes that may affect users.