RFC 9931 / START HERE
Safe HTTP transitions, before the details
Security Considerations for Optimistic Protocol Transitions in HTTP/1.1
HTTP/1.1 exchanges requests and responses over a connection. CONNECT asks a proxy to turn that connection into a tunnel carrying another application’s bytes to a destination. Sending those bytes before the server agrees is called optimistic transmission. This RFC explains its security risks and updates RFCs 9112 and 9298.
Why it exists
A proxy can trust its client while receiving bytes controlled by an untrusted application. If CONNECT fails, those bytes can look like another HTTP request made by the trusted client. HTTP/1.1 clients forwarding untrusted TCP data must wait for 2xx success (status 200–299), send Connection: close, or do both. Servers normally close rejected CONNECT connections; the chapters explain the narrow known-wait exception and each protocol’s own rules.
A familiar example
A fictional desktop tool asks a proxy for a tunnel to chat.example:443 and already has a message ready. With the waiting policy, it keeps the message in a buffer until a 200 response confirms the tunnel. If the proxy rejects CONNECT, the held message is not forwarded as another HTTP request. The guide also illustrates the close-header alternative, server safeguards and the distinct TLS, WebSocket, UDP and IP rules.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- A transition needs confirmationAn HTTP/1.1 connection begins as HTTP. Upgrade and CONNECT ask to change what its later bytes mean.→
- When early bytes become a requestA proxy client can be trusted by its proxy server while forwarding bytes from an untrusted TCP application.→
- Hold payload until 2xxA waiting proxy client buffers the untrusted application’s payload until the CONNECT response proves that a tunnel exists.→
- The Connection: close alternativeA client can instead signal that HTTP persistence must end, so rejected CONNECT data cannot become another HTTP request.→
- Reject safely, with a narrow exceptionThe proxy server normally stops the entire connection after rejecting CONNECT, even when the client did not request close.→
- Existing tokens use different protectionsTLS, WebSocket, connect-udp and connect-ip already have different ways to avoid ambiguous optimistic data.→
- Design future transitions around trustA future protocol must account for untrusted sources and the old HTTP parser before choosing an optimistic start.→
This introduction explains RFC 9931 (2026). Read the original RFC ↗