6. Impact on HTTP Upgrade with Existing Upgrade Tokens

This section preserves the RFC text for optimistic HTTP/1.1 protocol transitions, including request smuggling risks, parser exploit risks, existing Upgrade tokens, HTTP CONNECT requirements, and IANA status.

6.  Impact on HTTP Upgrade with Existing Upgrade Tokens

   This section describes the impact of this document's considerations
   on some registered upgrade tokens [IANA-UPGR] that are believed to be
   in use at the time of writing.

6.1.  "TLS"

   The "TLS" family of upgrade tokens was defined in [RFC2817], which
   correctly highlights the possibility of the server rejecting the
   upgrade.  If a client ignores this possibility and sends TLS data
   optimistically, the result cannot be valid HTTP/1.1: The first octet
   of a TLS connection must be 22 (ContentType.handshake), but this is
   not an allowed character in an HTTP/1.1 method (see [TLS],
   Section 5.1 and [HTTP/1.1], Section 3).  A compliant HTTP/1.1 server
   will treat this as a parsing error and close the connection without
   processing further requests.

6.2.  "WebSocket"/"websocket"

   Section 4.1 of [WEBSOCKET] says:

   |  Once the client's opening handshake has been sent, the client MUST
   |  wait for a response from the server before sending any further
   |  data.

   Thus, optimistic use of HTTP Upgrade is already forbidden in the
   WebSocket protocol.  Additionally, the WebSocket protocol requires
   high-entropy masking of client-to-server frames (Section 5.1 of
   [WEBSOCKET]).

6.3.  "connect-udp"

   Section 5 of [CONNECT-UDP] says:

   |  A client MAY optimistically start sending UDP packets in HTTP
   |  Datagrams before receiving the response to its UDP proxying
   |  request.

   However, in HTTP/1.1, this "proxying request" is an HTTP Upgrade
   request.  This upgrade is likely to be rejected in certain
   circumstances, such as when the UDP destination address (which is
   attacker-controlled) is invalid.  Additionally, the contents of the
   "connect-udp" protocol stream can include untrusted material (i.e.,
   the UDP packets, which might come from other applications on the
   client device).  This creates the possibility of Request Smuggling
   attacks.  To avoid these concerns, this document replaces that text
   to exclude HTTP/1.1 from any optimistic sending, as follows:

   |  A client MAY optimistically start sending UDP packets in HTTP
   |  Datagrams before receiving the response to its UDP proxying
   |  request but only if the HTTP version in use is HTTP/2 or later.
   |  Clients MUST NOT send UDP packets optimistically in HTTP/1.x due
   |  to the risk of Request Smuggling attacks.

6.4.  "connect-ip"

   The "connect-ip" upgrade token is defined in [CONNECT-IP].
   Section 11 of [CONNECT-IP] forbids clients from sending packets
   optimistically in HTTP/1.1, avoiding this issue.