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
Starting Rack 3.0 it's enforced at least in development mode to conform with HTTP/2 specification. It's touching in many aspects of the response and especially on header keys format.
It's recommended/enforced to have lower-case header keys in response. Technically, HTTP spec defines header keys as case-insensitive
At the same time it's a potentially-dangerous move:
I think requiring lower case headers has the potential to break lots of rack applications, frameworks, and middleware. However, it would also simplify a lot of code in the long run. Since HTTP/2 requires it and HTTP/1 works fine with it, it seems a reasonable change for SPEC. I definitely prefer this approach over requiring that response headers be case insensitive.
(by jeremyevans)
But I think we should keep an 👀 on that progress.
Note
In AppSec we return 403 response if InApp-WAF rule triggered and blocked the request. We have camel-case headers set in response object.
Starting Rack 3.0 it's enforced at least in
development
mode to conform with HTTP/2 specification. It's touching in many aspects of the response and especially on header keys format.It's recommended/enforced to have lower-case header keys in response. Technically, HTTP spec defines header keys as case-insensitive
At the same time it's a potentially-dangerous move:
But I think we should keep an 👀 on that progress.
Note
In AppSec we return 403 response if InApp-WAF rule triggered and blocked the request. We have camel-case headers set in response object.
Thanks @y9v for investigation support
The text was updated successfully, but these errors were encountered: