Wait for server opt-in
01A server setting enables Extended CONNECT on new streams. A client must learn that support before using the extension.
Separate invalid-send example: the same sender previously sent 1 and now attempts 0. MUST NOT applies at the sending gate; no valid rollback packet is delivered.
Source for this drawing: RFC 8441 · 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
- Setting
- A connection-level HTTP/2 parameter exchanged by the protocol stacks.
- Stream
- An individually identified exchange within one HTTP/2 connection.
- Pseudo-header
- A protocol-defined HTTP/2 field whose name begins with a colon.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A shared connection needs an explicit opt-in.
- SETTINGS_ENABLE_CONNECT_PROTOCOL has code 0x8, initial value 0, and a value that MUST be either 0 or 1.
- After receiving value 1, a client MAY use Extended CONNECT when creating new streams. This is permission, not an obligation or proof of application access.
- A sender MUST NOT send value 0 after it previously sent value 1. Receipt of the setting by a server has no impact.
The final state is a separate forbidden-setting example, not a valid rollback. An unsupported peer would regard an unnegotiated Extended CONNECT as malformed. No new universal rejection status or setting-reset algorithm is invented.
Read the RFC section ↗