-
Notifications
You must be signed in to change notification settings - Fork 43
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
Changing HTTP version on a connection #127
Comments
Something like this in 2.2 HTTP Version:
|
I don't see any reason to outlaw it, and I can't remember any properties of the whole connection (hop-by-hop doesn't exist any more outside of headers listed in Connection). We don't define 0.9 right now. Changing to 0.9 is a one-way, end of connection deal; it has no advantages of 1.1 smuggles. I do know that Apache will programmatically downgrade an HTTP response based on an environment variable that could be set by any characteristic of the received request or preparing the response to be sent. We had to do that due to broken proxies advertising 1.1 support. |
In general, I am a strong -1 to any requirement that makes HTTP session/connection bound instead of message-based. We might as well stop calling it HTTP at that point. If we have a known attack that needs to be addressed, I think we should try other fixes first. |
A logical scenario, for example, might be that a client sends e.g. HTTP/1.1, gets an HTTP/0.9 response, and proceeds to use HTTP/0.9 for the remainder of the connection because that's what the server can speak. However, there's clearly no ability to change versions on an HTTP/2 or HQ connection, so this is really a property of [0.9,1.x], not of HTTP in general. |
There is only one 0.9 response: the remainder of the connection. |
Closing with no action; if anyone disagrees, please complain. |
Is it useful to allow a version to change on a connection -- e.g., from 1.1 to 1.0 or 0.9 -- without using Upgrade explicitly?
Given that the version is declared per-message but it affects properties of the whole connection, and it's hop-by-hop, it seems like allowing it to change is an opportunity for various attacks (e.g. smuggling). Should we advise implementations to disallow?
The text was updated successfully, but these errors were encountered: