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
Describe the bug
By default, @middy/http-cors sets the Vary: Origin header, which is good.
However, it only does so based on whether the Access-Control-Allow-Origin request header has been set and is not *. This condition does not quite capture whether the Origin request header has been used to compute the response.
Expected behaviour
The Vary: Origin response header should be set if and only if the CORS response (preflight or not) might change depending on the Origin request header. That's because the Origin will become part of the cache key used by any reverse proxy. See the standard and the RFC. This includes when then Origin request header is missing (i.e. non-CORS request), as mentioned in the standard and as explained in this blog post.
In the case of @middy/http-cors, the Origin request header is only used to compute (or not) Access-Control-Allow-Origin. This means:
If the getOrigin option is set, then Vary: Origin should be set since we don't know whether the Origin request header is used by the custom function or not (and it probably is).
Else, if either the origin option is * or the origins option is an array containing *, then:
If the credentials option is false (its default value): Vary: Origin should not be set since Allow-Control-Allow-Origin will always be *.
Else, Vary: Origin should be set since Allow-Control-Allow-Origin will reflect the Origin request header.
Else, if both the origin option is not * and the origins option is an empty array (the default value), then Vary: Origin should not be set since the origin option will be used regardless of the Origin request header.
Additional context
Note: if the Vary response header is already set, this middleware will keep it as is, instead of concatenating its value with commas. See the code used by Express for this.
The text was updated successfully, but these errors were encountered:
Describe the bug
By default,
@middy/http-cors
sets theVary: Origin
header, which is good.However, it only does so based on whether the
Access-Control-Allow-Origin
request header has been set and is not*
. This condition does not quite capture whether theOrigin
request header has been used to compute the response.middy/packages/http-cors/index.js
Lines 134 to 144 in f50d235
Expected behaviour
The
Vary: Origin
response header should be set if and only if the CORS response (preflight or not) might change depending on theOrigin
request header. That's because theOrigin
will become part of the cache key used by any reverse proxy. See the standard and the RFC. This includes when thenOrigin
request header is missing (i.e. non-CORS request), as mentioned in the standard and as explained in this blog post.In the case of
@middy/http-cors
, theOrigin
request header is only used to compute (or not)Access-Control-Allow-Origin
. This means:getOrigin
option is set, thenVary: Origin
should be set since we don't know whether theOrigin
request header is used by the custom function or not (and it probably is).origin
option is*
or theorigins
option is an array containing*
, then:false
(its default value):Vary: Origin
should not be set sinceAllow-Control-Allow-Origin
will always be*
.Vary: Origin
should be set sinceAllow-Control-Allow-Origin
will reflect theOrigin
request header.origin
option is not*
and theorigins
option is an empty array (the default value), thenVary: Origin
should not be set since theorigin
option will be used regardless of theOrigin
request header.Additional context
Note: if the
Vary
response header is already set, this middleware will keep it as is, instead of concatenating its value with commas. See the code used by Express for this.The text was updated successfully, but these errors were encountered: