You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// Spec says: Since the list of methods can be unbounded, simply returning the method indicated// by Access-Control-Request-Method (if supported) can be enough
Such unwarranted case normalisation causes problems for clients that send requests whose method is not uppercase—and not some case-insensitive match for one of DELETE, GET, HEAD, OPTIONS, POST, or PUT, names for which the Fetch standard carves out an exception. Here is an example:
Assume then that a client running in the context of Web origin https://example.com in a Fetch-compliant browser sends a patch request (note the lower case) to the server. As go-chi/cors internally normalises method names to uppercase, the preflight response would contain
Access-Control-Allow-Methods: PATCH
as opposed to
Access-Control-Allow-Methods: patch
Browsers rule this as a mismatch and fail CORS preflight with an error message of this kind:
Access to fetch at [REDACTED] from origin ‘https://example.com’ has been blocked by CORS policy: Method patch is not allowed by Access-Control-Allow-Methods in preflight response.
For this reason, go-chi/cors should not normalise method names. More about this in one of my recent blog posts.
The text was updated successfully, but these errors were encountered:
Although method names are case-sensitive, go-chi/cors takes the unusual approach of normalising method names by uppercasing them:
Such unwarranted case normalisation causes problems for clients that send requests whose method is not uppercase—and not some case-insensitive match for one of
DELETE
,GET
,HEAD
,OPTIONS
,POST
, orPUT
, names for which the Fetch standard carves out an exception. Here is an example:Assume then that a client running in the context of Web origin
https://example.com
in a Fetch-compliant browser sends a patch request (note the lower case) to the server. As go-chi/cors internally normalises method names to uppercase, the preflight response would containAccess-Control-Allow-Methods: PATCH
as opposed to
Access-Control-Allow-Methods: patch
Browsers rule this as a mismatch and fail CORS preflight with an error message of this kind:
For this reason, go-chi/cors should not normalise method names. More about this in one of my recent blog posts.
The text was updated successfully, but these errors were encountered: