A transition needs confirmation
01An HTTP/1.1 connection begins as HTTP. Upgrade and CONNECT ask to change what its later bytes mean.
An ordinary rejected Upgrade may continue as HTTP/1.1. CONNECT rejection has the specific default closure and known-wait exception in RFC 9931 §8; it is not a successful tunnel.
Source for this drawing: RFC 9931 · Read RFC section 3 ↗
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.
Finish the request, then distinguish permission from optimism.
- An Upgrade request is accepted with 101 (Switching Protocols). A successful CONNECT uses a 2xx response and turns the connection into a tunnel.
- The entire HTTP request must be complete before the client begins the new protocol. Completion alone does not mean that the server accepted the transition.
- Optimistic data is sent before acceptance to save a round trip. General Upgrade rejection can leave HTTP/1.1 usable; the updated CONNECT rejection rule and its exception are covered later.
A tunnel carries bytes to another destination. It does not make those bytes HTTP or trustworthy. This guide concerns HTTP/1.1 connection transitions, not an instruction to close every rejected Upgrade.
Read the RFC section ↗