-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
X-Cascade header Rack 3 issue #2354
Comments
Related to #2254 |
This is what they are doing for Sidekiq Web: if Gem::Version.new(Rack::RELEASE) < Gem::Version.new("3")
CONTENT_LANGUAGE = "Content-Language"
CONTENT_SECURITY_POLICY = "Content-Security-Policy"
LOCATION = "Location"
X_CASCADE = "X-Cascade"
else
CONTENT_LANGUAGE = "content-language"
CONTENT_SECURITY_POLICY = "content-security-policy"
LOCATION = "location"
X_CASCADE = "x-cascade"
end Would something similar in Grape Headers work? |
It would probably work. Start by writing a Rails 6 and 7 spec? |
Another option could be to make the
|
@dblock I've thrown something together for both approaches, please let me know your thoughts and whether either of these is going in the right direction: |
From rack/rack#1592 "I suggest with Rack 3.0 we take the opportunity to enforce the HTTP/2 semantics. It also simplifies the requirements around headers being a hash, to the point where I think it would be acceptable for Rack 3.0." It feels like we should major-version increment grape if we're going to make a change like this, and lowercase all header names everywhere? |
Closed via #2355. |
The
X-Cascade
header in Rack 3 applications appears to need to be lower case, and so it currently doesn't work as expected in Grape apps using Rack 3 usingcascade: true
.The following spec, which passes in Rack 2, fails as the default response is returned from Grape instead.
Manually updating my local Grape gem to use
x-cascade
results in the spec passing again.The text was updated successfully, but these errors were encountered: