Reject safely, with a narrow exception
05The proxy server normally stops the entire connection after rejecting CONNECT, even when the client did not request close.
Even a known waiting client that sends Connection: close requests the ordinary HTTP closure behavior. Disabling the extra mitigation does not cancel that request option.
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.
Close by default; exempt only a client known to wait.
- Proxy servers MUST close the underlying connection when rejecting CONNECT, without processing any further requests on it. This applies with or without a close connection option.
- As a performance optimization, a server MAY disable this mitigation if the client is known to wait for 2xx before forwarding untrusted TCP payload. The exception is permission, not an obligation to keep the connection open.
- The RFC mentions User-Agent plus vendor compliance documentation to identify such clients. An arbitrary User-Agent claim alone is not authenticated evidence. A Connection: close request still requires ordinary closure even for a known waiting client.
- Closure can slow connection establishment, particularly a 407 proxy-authentication retry. HTTP/2 and HTTP/3 avoid this particular connection-level request-smuggling attack.
The exception is tied to item 1 (waiting), not merely item 2 (sending close). Do not turn this into a general rejection rule for all Upgrade requests, or a claim that HTTP/2 and HTTP/3 have no security risks.
Read the RFC section ↗