Hold payload until 2xx
03A waiting proxy client buffers the untrusted application’s payload until the CONNECT response proves that a tunnel exists.
The client forwards the buffered payload into the accepted tunnel once. Separate failure outcome: a non-2xx final response leaves the payload unforwarded.
Source for this drawing: RFC 9931 · Read RFC section 8 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A complete request and a successful final response open the data gate.
- For HTTP/1.1 CONNECT on behalf of untrusted TCP clients, the proxy client MUST wait for 2xx before forwarding any TCP payload, send Connection: close, or do both.
- With the waiting policy, informational responses do not open the tunnel. Only a 2xx response allows the buffered TCP payload to be forwarded.
- If CONNECT fails, do not forward the held payload as HTTP requests. The server’s default rejection closure prevents processing further requests; a known-wait exception is explained in chapter five.
The buffer illustrates a bounded teaching example, not a production queue or resource-limit design. Waiting is one permitted mitigation, not the only permitted mitigation. Successful tunneling does not supply application authentication.
Read the RFC section ↗