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: This avoids having to determine whether is an actual existing standard or not. This is an alternative to
Merging for draft cutoff.
The lists an entry for HTTP/.\, and specifically identifies "2.0" as a possible version value, as instructed by . However, this flow seems to have been superseded by "Upgrade: h2c", which was introduced in RFC 7540 and deprecated in RFC 9113. I am not aware of any implementations of "Upgrade: HTTP/2.0" in clients or servers. I think we have two main options: Status Quo: Regard "HTTP/.\" as a mechanism that is formally defined but not implemented anywhere. Provide formal analysis of its security for completeness. Deprecation: Update RFC 9110 in this draft to remove the definition of this upgrade token. Mark "HTTP" as "obsolete" in the Upgrade Tokens Registry.
Moving discussion over to the issue, perhaps. Upgrading to TLS is a defined thing that gets used; I'm not clear that we need to deprecate that. Upgrading to future HTTP versions is a little more interesting. Certainly it's illegal to upgrade to or because upgrade isn't defined by those specifications. RFC 7540 defines a distinct token, RFC 9113 deprecates it, and RFC 9114 does not define an Upgrade path for obvious reasons. It certainly looks like we've decided not to use this mechanism for changing HTTP versions. Does that mean we should eliminate it? I'm not opposed, but I'm also not certain we need to go there.
Moving to TLS with upgrade (i.e., RFC 2817) is now so much of a niche thing that I think that deprecation would be wise. We've heard that it is still in use, but it's certainly not inoperable in quite the same way as other parts of the protocol. Either way, I think it would be better to write a separate document deprecating Upgrade (either completely or more narrowly) than to sneak it in here. This document can point out that it is unsafe in the ways in which it is unsafe, but it doesn't need to make the deeper cut to achieve that.
It seems clear that we don't want to deprecate in this document, so I've removed that text from . I've kept open to discuss the fate of .