Code change:
5. <del> At the time of writing, there are four distinct Upgrade Tokens that are registered, associated with published documents, and not marked obsolete.  This section considers the impact of this document's considerations on each registered Upgrade Token. </del> <ins> This section describes the impact of this document's considerations on some registered Upgrade Tokens that are believed to be in use at the time of writing. </ins> 5.1. <del> RFC9110 is the source of the requirement quoted in background.  It also defines the "HTTP/*.*" family of Upgrade Tokens.  In HTTP/1.1, the only potentially applicable versions of this token are "0.9", "1.0", "1.1", and "2.0". Versions "0.9" and "1.0" are sufficiently syntactically similar to HTTP/1.1 that any such "downward upgrade" would be unlikely to result in the security concerns discussed here.  (An "upgrade" to version 1.1 has no effect at all.) A version number of "2.0" corresponds to HTTP/2.  Every HTTP/2 connection begins with a Client Connection Preface (RFC9113) that was selected to ensure that a compliant HTTP/1.1 server will not process further data on this connection.  This avoids security issues if an "HTTP/2.0" Upgrade Token is used optimistically. 5.2. </del> RFC2817 defines the "TLS/ " family of Upgrade Tokens, and correctly highlights the possibility

Related discussion:
text: The WG seems to believe that this mechanism is already deprecated, if it was ever defined at all, and the IANA registry entry is just misleading or incorrect.
The trouble is that exists in a sort of quantum superposition of standardized and deprecated, but that will collapse if we mention it in this draft in any way. The options I see are: Don't claim (as the current text does) to present an exhaustive analysis of the defined Upgrade Tokens, and silently ignore the registration of . Treat it as a live standard. Declare that it was already deprecated. Deprecate it.
I'd say deprecating isn't particularly useful or interesting, since that doesn't impact implementations. If we can't agree on which quantum state we are in and want to be in at the same time, then I'd leave the cat in the box. The more interesting question is: should implementations do something to protect against a dangerous ? For h2, the preface should protect against smuggling. Where do we stand for other versions, is there a risk we should warn implementers about?
My expectation is that implementations of do not exist, and never will, so I don't think it's very useful to provide guidance to them. There's a question of whether one can even speak about a "downward Upgrade" from HTTP/1.1 to 0.9-1.1. Assuming that is allowed, I think 1.0 and 1.1 are safe, if we assume that the HTTP-Version line is sent/repeated at this point. (Does Upgrade: HTTP create a new HTTP connection or re-version the existing one???) They both start with "HTTP/1", which is not a valid method name due to the "/". HTTP/0.9 is possibly more interesting since it does not send an HTTP-Version line. I don't see a way for the server to figure out whether the client is speaking HTTP/1.1 (after the rejected upgrade) or HTTP/0.9 (optimistically). However, I don't think this poses a security threat, so long as the attacker-controlled data is the same in HTTP/1.1 as it is in HTTP/0.9.