-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Stop setting HTTP_VERSION to SERVER_PROTOCOL #970
Comments
I don't do this in |
Rack is still setting |
Moving this to v3.0.0 milestone. |
IMO it's fine to remove this for v3.0.0 |
This spec failed: Thin::Request parser should not fuck up on stupid fucked IE6 headers with: should validate with Rack Lint: env[HTTP_VERSION] does not equal env[SERVER_PROTOCOL] where: "HTTP_VERSION"=>"HTTP/1.0", "SERVER_PROTOCOL"=>"HTTP/1.1", Indeed: > Rack::HTTP_VERSION has been removed and the HTTP_VERSION env setting is no longer set in the CGI and Webrick handlers See: - rack/rack#970 - rack/rack#969 - rack/rack#1691 The version is necessary to negotiate `persistent?`, so here we punt on a further refactoring to find a good way to get the request HTTP version from the first line, instead shoving it in a Thin-specific `thin.request_http_header`.
I'm opening this to discuss the merits and reasonings for setting HTTP_VERSION inside of the different rack handlers.
See my "Notes" under #969 for a little bit of context.
tl;dr is in all of the handlers, rack does this little bit:
This causes an environment variable to get set to for
HTTP_VERSION
, when according to the CGI spec,HTTP_*
is explicitly reserved for client headers. This makes it confusing if something downstream is attempting to collect all client headers, this becomes ambiguous. Did the client sent aVersion
header? Or is this theVersion
header that Rack is declaring?This behavior is wrong, but I'm not sure of the ramification of simply... stopping doing this. I can't seem to find things that reference this, except the internals that were fixed up in #969, but no idea how common this is downstream to actually use this value.
The text was updated successfully, but these errors were encountered: