-
Notifications
You must be signed in to change notification settings - Fork 37
Description
Although method names are case-sensitive, go-chi/cors takes the unusual approach of normalising method names by uppercasing them:
// 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:
c := cors.New(cors.Options{
AllowedOrigins: []string{"https://example.com"},
AllowedMethods: []string{"patch"},
})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: PATCHas opposed to
Access-Control-Allow-Methods: patchBrowsers 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.