Vary: Origin should be set on non-CORS request #330
Description
By default, the Vary: Origin response header is set, which is good. However, it is not set if the Origin request header is missing (i.e. on non-CORS requests).
Lines 220 to 222 in 53312a5
That's an error as mentioned in the standard.
In particular, consider what happens if
Varyis not used and a server is configured to sendAccess-Control-Allow-Originfor a certain resource only in response to a CORS request. When a user agent receives a response to a non-CORS request for that resource (for example, as the result of a navigation request), the response will lackAccess-Control-Allow-Originand the user agent will cache that response. Then, if the user agent subsequently encounters a CORS request for the resource, it will use that cached response from the previous non-CORS request, withoutAccess-Control-Allow-Origin.But if
Vary: Originis used in the same scenario described above, it will cause the user agent to fetch a response that includesAccess-Control-Allow-Origin, rather than using the cached response from the previous non-CORS request that lacksAccess-Control-Allow-Origin.
Also in this blog post.
The rule here is simple: If your server makes a decision about what to return based on a what’s in a HTTP header, you need to include that header name in your Vary, even if the request didn’t include that header.
One thing to add here: if the Origin request header is ignored when computing any CORS response, then Vary: Origin should not be set (regardless of whether the Origin request header was used or not). In practice, this is when the origin option is false or a string (the default value), as opposed to when it is true, a regular expression, an array or a function. (see #332).