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
The vary option only seems to be honored for a specific resource for requests made with HTTP methods other than the pre-flight OPTIONS requests.
Whether or not the vary option is set for specific resource, no vary headers will be sent when the request uses the OPTIONS method.
This seems to cause a problem with Chrome where it caches the response for the period of time that is configured for max_age, which can be a problem for the use-case where Access-Control-Allow-Origin will neither be "*" nor a single static origin: https://fetch.spec.whatwg.org/#cors-protocol-and-http-caches
The work-around of course would be to set a very low max_age or to use a configuration option outside of rack-cors to set the vary header(s).
I recognize that this is a very old comment, but I wondered if it's still the design of rack-cors: #73 (comment)
To reproduce, I am using rack-cors v1.1.1 and my config.ru is, where I currently have all http origins allowed (contrary to the nature of this issue) but would like to make the origins a conditional depending on a dynamic list of configured OIDC client URLs so that it will not simply be "*":
require 'rack/cors'
use Rack::Cors do
allow do
origins /\Ahttp.*/ # this should be a lookup for configured http and https OIDC clients
resource '/oauth/*', headers: :any, methods: [:get, :post],
max_age: 600,
vary: ['Origin']
end
end
require ::File.expand_path('../config/environment', __FILE__)
run Rails.application
moduleRackclassCorsclassResourcedefto_preflight_headers(env)h=to_headers(env)h.merge!('Vary'=>vary_headers.join)# <== The patchifenv[HTTP_ACCESS_CONTROL_REQUEST_HEADERS]h.merge!('Access-Control-Allow-Headers'=>env[HTTP_ACCESS_CONTROL_REQUEST_HEADERS])endhendendendend
Caveat: I may have a misconfiguration.
The
vary
option only seems to be honored for a specificresource
for requests made with HTTP methods other than the pre-flightOPTIONS
requests.Whether or not the
vary
option is set for specificresource
, novary
headers will be sent when the request uses theOPTIONS
method.This seems to cause a problem with Chrome where it caches the response for the period of time that is configured for
max_age
, which can be a problem for the use-case whereAccess-Control-Allow-Origin
will neither be "*" nor a single static origin:https://fetch.spec.whatwg.org/#cors-protocol-and-http-caches
The work-around of course would be to set a very low
max_age
or to use a configuration option outside ofrack-cors
to set thevary
header(s).I recognize that this is a very old comment, but I wondered if it's still the design of
rack-cors
:#73 (comment)
To reproduce, I am using
rack-cors
v1.1.1 and myconfig.ru
is, where I currently have all http origins allowed (contrary to the nature of this issue) but would like to make theorigins
a conditional depending on a dynamic list of configured OIDC client URLs so that it will not simply be "*":For an example of how Google responds:
Where Google replies with:
The text was updated successfully, but these errors were encountered: