Future upgrade tokens should be restricted to GET requests with no content when the HTTP method is otherwise irrelevant and the request does not need to carry message content. This improves consistency with existing upgrade tokens (WebSocket, connect-udp, connect-ip) and simplifies server implementation.

http

HTTP/1.1 is the only HTTP version that allows clients to change the protocol mid-connection. HTTP/2 and HTTP/3 use explicit stream IDs for multiplexing, making them structurally immune to the Request Smuggling attack described in this document. Migrating to HTTP/2 or HTTP/3 is the recommended long-term solution.

http, security

The optimistic sending pattern is motivated by latency reduction: if a previous transition request with the same upgrade token succeeded, the client may predict future success and send new-protocol data before receiving the server's response. This document demonstrates that the pattern is unsafe in HTTP/1.1 when third-party data is involved.

http, security

The server-side mitigation (closing the connection on CONNECT rejection) is acknowledged to cause performance degradation, especially when returning 407 responses requiring re-authentication. The document explicitly notes this cost can be avoided by upgrading clients and servers to HTTP/2 or HTTP/3, which are not vulnerable to this attack.

http, security

Three design patterns are recommended for future upgrade tokens to reduce or eliminate optimistic-transition security issues: (1) forbid optimistic use of HTTP Upgrade entirely, (2) embed a fixed preamble that deliberately terminates HTTP/1.1 processing, or (3) apply high-entropy masking to client-to-server data. Existing tokens (WebSocket, connect-ip, HTTP/2) each exemplify one of these approaches.

http, security

The 'connect-ip' upgrade token (RFC 9484) already forbids clients from sending packets optimistically in HTTP/1.1 (Section 11 of RFC 9484), so this document's concerns do not require any updates to that specification.

http, security

The 'TLS' upgrade token is self-mitigating: optimistic TLS data begins with octet 22 (ContentType.handshake), which is not an allowed character in an HTTP/1.1 method. A compliant HTTP/1.1 server will treat this as a parse error and close the connection, preventing Request Smuggling but also preventing connection reuse.

http, tls, security

The WebSocket protocol already forbids optimistic use of HTTP Upgrade: RFC 6455 Section 4.1 requires the client to wait for the server's response before sending any further data. Additionally, WebSocket mandates high-entropy masking of all client-to-server frames, providing a second layer of protection.

http, websocket, security

A client cannot begin using an upgraded protocol on the connection until it has completely sent the request message; this is a necessary but not sufficient condition, as the server might reject the transition. Completion of the request is required before switching protocols.

http

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

http, security, udp

Proxy clients that send CONNECT requests on behalf of untrusted TCP clients MUST either wait for a 2xx (Successful) response before forwarding any TCP payload data, or send a 'Connection: close' request header. Clients not implementing at least one of these behaviors are vulnerable to a trivial Request Smuggling attack.

http, security

Proxy servers MAY disable the CONNECT-rejection close mitigation if the client is known to wait for a 2xx response before forwarding untrusted TCP payload data. Servers can identify compliant clients via the User-Agent header field and vendor documentation.

http, security

Proxy servers MUST close the underlying connection when rejecting a CONNECT request, without processing any further requests on that connection. This applies whether or not the request includes a 'close' connection option, and serves as a server-side mitigation for vulnerable proxy clients.

http, security

There is no general requirement to close an HTTP/1.1 connection after a rejected protocol transition; it is normally inappropriate to do so, as the connection can continue to be used for HTTP/1.1 requests. Keeping it open has performance advantages if additional requests are likely.

http

HTTP/1.1 provides two mechanisms for protocol transitions on an existing connection: the Upgrade header field (RFC 9110, Section 7.8), which results in a 101 Switching Protocols response on acceptance, and the CONNECT method (RFC 9110, Section 9.3.6), which establishes a TCP tunnel and results in a 2xx response on acceptance. Both may be rejected by the server.

http

Parser Exploits are a related risk: even when the HTTP client is trusted, optimistic transmission of post-transition data from an untrusted source can violate assumptions built into the server's HTTP request parser, exposing vulnerabilities in parsing logic developed without expecting attacker-controlled input.

http, security

Request Smuggling is the primary security risk from optimistic protocol transitions. If a client sends post-transition data before the server confirms the upgrade, and the server rejects the transition, attacker-controlled data in the new protocol stream may be misinterpreted as a subsequent authenticated HTTP/1.1 request issued by the client.

http, security

Security risks from optimistic transitions arise specifically in multi-party connections where third-party data is attacker-controlled. In a purely two-party connection, protocol transitions introduce no new security issues because each party must already be prepared for arbitrary data.

http, security