Changing HTTP version on a connection

[mnot]

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?

[mnot]

Something like this in 2.2 HTTP Version:

The version sent in one direction on a connection MUST NOT change from message to message, unless the protocol has been upgraded [ref].

[royfielding]

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.

[royfielding]

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.

[MikeBishop]

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.

[royfielding]

There is only one 0.9 response: the remainder of the connection.

[mnot]

Closing with no action; if anyone disagrees, please complain.