RFC 9931

Security Considerations for Optimistic Protocol Transitions in HTTP/1.1

📅 published March 2026, from ietf

RFC 9931: Security Considerations for Optimistic Protocol Transitions in HTTP/1.1 🦋

  • Published by: the Internet Engineering Task Force (IETF) 🌈
  • Author: B. Schwartz, Meta Platforms, Inc. 💖
  • Category: Standards Track 🎀
  • Date: March 2026 🌸
  • Updates: RFC 9112 and RFC 9298 🔥
  • ISSN: 2070-1721 ✨

Abstract ✨

okay so in HTTP/1.1 the client can ask to switch to a new protocol on the same connection 👀. This doc is all about the security stuff that comes up when the client sends data BEFORE the server has said yes, and it adds new requirements to RFC 9112 and RFC 9298 so we don't end up with related security drama 💅.

Status of This Memo 📝

bestie, this is an Internet Standards Track document 🏆.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9931.

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents 🗂️

1.  Overview
2.  Requirements Language
3.  Background
4.  Possible Security Issues
  4.1.  Request Smuggling
  4.2.  Parser Exploits
5.  Operational Issues
6.  Impact on HTTP Upgrade with Existing Upgrade Tokens
  6.1.  "TLS"
  6.2.  "WebSocket"/"websocket"
  6.3.  "connect-udp"
  6.4.  "connect-ip"
7.  Guidance for Future Upgrade Tokens
  7.1.  Selection of Request Methods
8.  Requirements for HTTP CONNECT
9.  Security Considerations
10. IANA Considerations
11. References
  11.1.  Normative References
  11.2.  Informative References
Acknowledgments
Author's Address

1. Overview 🌟

this doc digs into the security considerations that show up when you switch from HTTP/1.1 to a different protocol on the same connection 🦋. It gives you:

  • a review of the relevant standards,
  • a discussion of the security risks that may apply if a client sends data before the transition is confirmed,
  • a security evaluation of existing upgrade tokens, and
  • guidance for implementations and future standards documents.

the updates to [HTTP/1.1] and [CONNECT-UDP], including the new normative requirements, live in Sections 8 and 6.3, respectively 💜.

2. Requirements Language 📏

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document get the BCP 14 treatment ([RFC2119] [RFC8174]). That only happens when they show up in all capitals, exactly like this 🔠. Lowercase is just regular English, bestie 🙈.

3. Background 📚

In HTTP/1.1 [HTTP/1.1] and later, a single connection can be used for many requests. In HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3], these requests can be multiplexed, since each request is distinguished explicitly by its stream ID. However, in HTTP/1.1 requests are strictly sequential, and each new request is distinguished implicitly by the closure of the preceding request.

HTTP/1.1 is also the only version of HTTP that lets the client change the protocol used for the rest of the connection 😳. There are two mechanisms to request that kind of protocol transition. The first is the Upgrade header field ([HTTP], Section 7.8). When it's included in a request, it says the client would like to use this connection for a protocol other than HTTP/1.1. The server replies with a 101 (Switching Protocols) status code if it accepts the protocol change ([HTTP], Section 15.2.2).

The other mechanism is the HTTP CONNECT method (Section 9.3.6 of [HTTP]). This method says the client wants to establish a TCP connection to the specified host and port. If it's accepted, the server replies with a 2xx (Successful) response to show that the request was accepted and a TCP connection was established. After that point, the TCP connection is acting as a TCP tunnel, not an HTTP/1.1 connection 🚇.

Both of these mechanisms also let the server reject the request. For example, Section 7.8 of [HTTP] says:

A server MAY ignore a received Upgrade header field if it wishes to continue using the current protocol on that connection.

and Section 9.3.6 of [HTTP] says:

A server MUST reject a CONNECT request that targets an empty or invalid port number, typically by responding with a 400 (Bad Request) status code.

Rejected upgrades are super common and can happen for lots of reasons, like:

  • The server doesn't support any of the client's indicated upgrade tokens (i.e., the client's proposed new protocols), so it keeps using HTTP/1.1.
  • The server knows that upgrading to the offered protocol won't improve anything over HTTP/1.1 for this request to this resource, so it chooses to respond in HTTP/1.1.
  • The server requires the client to authenticate before upgrading the protocol, so it replies with the status code 401 (Authentication Required) and provides a challenge in an Authorization response header field ([HTTP], Section 11.6.2).
  • The resource has moved, so the server replies with a 3xx (Redirection) status code ([HTTP], Section 3.4).

Servers also reject HTTP CONNECT requests a lot, like when:

  • The server doesn't support HTTP CONNECT.
  • The specified destination isn't allowed under server policy.
  • The destination can't be resolved, is unreachable, or doesn't accept the connection.
  • The proxy requires the client to authenticate before proceeding.

After rejecting a request, the server keeps interpreting the bytes it receives on that connection according to HTTP/1.1 🔁.

Section 7.8 of [HTTP] also states:

A client cannot begin using an upgraded protocol on the connection until it has completely sent the request message (i.e., the client can't change the protocol it is sending in the middle of a message).

so in other words, finishing the request message is a necessary condition for the client to start using the new protocol. But it's important to clarify that it is NOT a sufficient condition, because the server might still reject the request 🚫.

Sometimes the client can predict that the server is likely to accept a requested protocol transition. For example, if a request using an upgrade token recently succeeded, the client might expect that later requests with the same upgrade token will succeed too. If that expectation is right, the client can often cut down on delay by immediately sending the first bytes of the new protocol "optimistically", without waiting for the server's response ⏩. This document explores the security implications of this "optimistic" behavior 🔍.

4. Possible Security Issues 🚨

When only two distinct parties are involved in an HTTP/1.1 connection (the client and the server), protocol transitions introduce no new security issues. Each party already has to be ready for the other to send arbitrary data on the connection at any time. However, HTTP connections often involve more than two parties if the requests or responses include third-party data 👥. For example, a browser (party 1) might send an HTTP request to an origin (party 2) where the path, headers, or content are controlled by a website from a different origin (party 3). Post-transition protocols, such as WebSocket [WEBSOCKET], are also frequently used to carry data chosen by a third party 🧩.

If the third-party data source is untrusted, then the data it provides is potentially "attacker-controlled" 😈. Attacker-controlled data combined with optimistic protocol transitions leads to two significant security issues 💀.

4.1. Request Smuggling 🥷

In a Request Smuggling attack ([HTTP/1.1], Section 11.2), the attacker-controlled data is crafted so the server interprets it as an additional HTTP request. These attacks let the attacker speak on behalf of the client while getting around the client's own rules about which requests it will issue. Request Smuggling can happen if the client and server have different interpretations of the data flowing between them 👀.

If the server accepts a protocol transition request, it interprets the following bytes according to the new protocol. If it rejects the request, it interprets those bytes as HTTP/1.1. But the client can't know which interpretation the server will take until it gets the server's response status code 😬. If the client uses the new protocol optimistically, there's a risk that the server will read attacker-controlled data in the new protocol as an additional HTTP request issued by the client 🚩.

As a simple example, picture an HTTP CONNECT client providing connectivity to an untrusted application. If the client is authenticated to the proxy server using a connection-level authentication method, such as TLS Client Certificates ([TLS], Section 4.4.2), the attacker could send an HTTP/1.1 POST request ([HTTP], Section 9.3.3) to the proxy server at the start of its TCP connection 🕵️. If the client delivers this data optimistically and the CONNECT request fails, the server would misread the application's data as a later authenticated request issued by the client 💔.

## REQUESTS ##

# The malicious application requests a TCP connection to a nonexistent
# destination, which will fail.
CONNECT no-such-destination.example:443 HTTP/1.1
Host: no-such-destination.example:443

# Before connection fails, the malicious application sends data on the
# proxied TCP connection that forms a valid POST request to the proxy.
# The vulnerable client optimistically forwards this data to the proxy.
POST /upload HTTP/1.1
Host: proxy.example
Content-Length: 123456

<POST body controlled by the malicious application>

## RESPONSES ##

# When TCP connection establishment fails, the proxy responds by
# rejecting the CONNECT request, but the client has already forwarded
# the malicious TCP payload data to the proxy.
HTTP/1.1 504 Gateway Timeout
Content-Length: 0

# The proxy interprets the smuggled POST request as coming from the
# client.  If connection-based authentication is in use (e.g., using
# TLS client certificate authentication), the proxy treats this
# malicious request as authenticated.
HTTP/1.1 200 OK
Content-Length: 0

Figure 1: Example Request Smuggling Attack Using HTTP CONNECT 🌈✨

4.2. Parser Exploits ✨

okay so this one is a whole category of sneaky attacks 🕵️‍♀️ they work by exploiting a disagreement about the protocol to break the server's request parser 💀 the catch is the HTTP client is trusted by the server, but the data coming in after the transition is NOT trusted 🙈 if the server software was built on the assumption that some or all of the HTTP request data is not attacker-controlled, then optimistic sending can break that assumption and expose holes in the server's HTTP request parser 🔥 not me finding out parsers are this fragile 😭

5. Operational Issues 🌸

if the server rejects the transition request, the connection can keep being used for HTTP/1.1 🦋 there is no general requirement to close the connection in response to a rejected transition, and keeping it open has performance perks if more HTTP requests to that server are likely to show up 🚀 so it's normally inappropriate to close the connection in response to a rejected transition 💅

6. Impact on HTTP Upgrade with Existing Upgrade Tokens 🎀

this section is about how all of this affects some registered upgrade tokens [IANA-UPGR] that are believed to be in use at the time of writing 👑 the tea is spilled in the subsections below 🍵

6.1. "TLS" 🔐

the "TLS" family of upgrade tokens was defined in [RFC2817], which correctly calls out that the server might reject the upgrade ✅ if a client ignores that possibility and sends TLS data optimistically, the result can't be valid HTTP/1.1 🙃 the first octet of a TLS connection must be 22 (ContentType.handshake), but that's 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.

so optimistic use of HTTP Upgrade is already forbidden in the WebSocket protocol 🙅‍♀️ on top of that, the WebSocket protocol requires high-entropy masking of client-to-server frames (Section 5.1 of [WEBSOCKET]) 🧂 we love a protocol that's already thought this through 💜

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.

BUT 👀 in HTTP/1.1, this "proxying request" is an HTTP Upgrade request 🙃 that upgrade is likely to get rejected in certain situations, like when the UDP destination address (which is attacker-controlled) is invalid ❌ also, the contents of the "connect-udp" protocol stream can include untrusted material (aka the UDP packets, which might come from other applications on the client device) 😬 that opens the door to Request Smuggling attacks 🚨 to dodge all of this, this document replaces that text so HTTP/1.1 is excluded from any optimistic sending, like so:

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, so this issue gets avoided 🙌

7. Guidance for Future Upgrade Tokens 🔮

there are now several good examples of designs that reduce or eliminate the security concerns in this document, and they may be useful in future specs 💡

  • Forbid optimistic use of HTTP Upgrade (Section 4.1 of [WEBSOCKET] and Section 11 of [CONNECT-IP]).
  • Embed a fixed preamble that deliberately terminates HTTP/1.1 processing (Section 3.4 of [HTTP/2]).
  • Apply high-entropy masking of client-to-server data (Section 5.1 of [WEBSOCKET]).

future specs for upgrade tokens should account for the security issues discussed here and give clear guidance on how implementations can avoid them 🫶

7.1. Selection of Request Methods 🍓

some upgrade tokens, like "TLS", are defined for use with any ordinary HTTP method 💖 the upgraded protocol keeps providing HTTP semantics and will convey the response to that HTTP request ✨

the other upgrade tokens mentioned in Section 6 don't preserve HTTP semantics, so the method isn't relevant for them 🤷‍♀️ all of these upgrade tokens are specified only for GET requests with no content 🧁

future specifications for upgrade tokens should restrict their use to GET requests with no content if the HTTP method is otherwise irrelevant and the request doesn't need to carry any message content 💅 this improves consistency with other upgrade tokens and simplifies server implementation 🎀

8. Requirements for HTTP CONNECT 🩷

this document updates [HTTP/1.1] to include the remaining text of this section 📝 the requirements here apply only to HTTP/1.1 🙂

proxy clients that send CONNECT requests on behalf of untrusted TCP clients MUST do one or both of the following:

  1. Wait for a 2xx (Successful) response before forwarding any TCP payload data.
  2. Send a "Connection: close" request header.

proxy clients that don't implement at least one of these two behaviors are vulnerable to a trivial Request Smuggling attack ([HTTP/1.1], Section 11.2) 😱

at the time of writing, some proxy clients are believed to be vulnerable as described 🫣 as a mitigation, proxy servers MUST close the underlying connection when rejecting a CONNECT request, without processing any further requests on that connection 🚪 this requirement applies whether or not the request includes a "close" connection option 🔒

note that this mitigation will frequently cause slower connection establishment for correctly implemented clients, especially when returning a 407 (Proxy Authentication Required) response 🐢 this performance loss can be avoided by using HTTP/2 or HTTP/3, which are not vulnerable to this attack 🚀

as a performance optimization, proxy servers MAY disable this mitigation if the client is known to wait for a 2xx (Successful) response before forwarding untrusted TCP payload data (i.e., complying with item 1 above) 🧠 proxy servers can identify compliant clients using the request's User-Agent header field and the user agent vendor's documentation regarding its compliance 🔍

9. Security Considerations 🚨

this document describes security considerations related to optimistic use of protocol transitions in HTTP/1.1 💀 read the whole thing before you ship anything that sends data early, bestie 😭

10. IANA Considerations 🌷

this document has no IANA actions ✨

11. References 📚

11.1. Normative References

11.2. Informative References

Acknowledgments 🫶

this document benefited from valuable reviews and suggestions by:

  • Mike Bishop
  • Mohamed Boucadair
  • Gorry Fairhurst
  • Mark Nottingham
  • Kazuho Oku
  • Lucas Pardue
  • David Schinazi
  • Glenn Strauss
  • Michael Sweet
  • Willy Tarreau
  • Martin Thomson

Author's Address 💌

Benjamin M. Schwartz Meta Platforms, Inc. Email: ietf@bemasc.net

the end, bestie 🌈✨ that's the whole RFC 9931 glow-up 💖

📦 where this page comes from