The Connection: close alternative
04A client can instead signal that HTTP persistence must end, so rejected CONNECT data cannot become another HTTP request.
For an available destination in this alternate outcome, a 2xx response establishes the tunnel. HTTP persistence ends; the useful tunnel is not immediately closed merely because of this 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.
Implement one mitigation or both; do not silently drop the alternative.
- A CONNECT request has no content; its authority-form target includes an explicit port. End its header section with an empty line. The second permitted client mitigation is a Connection: close request header. A client may combine this with waiting for 2xx.
- In the header-only option, the complete CONNECT request precedes optimistic TCP payload. If CONNECT is rejected, the proxy server closes the underlying connection without processing further HTTP requests.
- If CONNECT succeeds with 2xx, subsequent bytes belong to the tunnel. Do not reinterpret the close option as an instruction to close a successfully established tunnel immediately.
Connection: close is an HTTP/1.1 connection option, not an application-data delimiter or an encryption mechanism. HTTP/1.1 connection persistence is defined in RFC 9112 §9.3; CONNECT success framing is §6.3. This drawing shows separate success and failure outcomes.
Read the RFC section ↗