Design future transitions around trust
07A future protocol must account for untrusted sources and the old HTTP parser before choosing an optimistic start.
HTTP/2 and HTTP/3 identify streams explicitly, avoiding this particular HTTP/1.1 whole-connection ambiguity. They still need their own security analysis. No registry action is performed here.
Source for this drawing: RFC 9931 · Read RFC section 7 ↗
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.
Choose deliberate protection; do not inherit safety by analogy.
- Consider who controls the first new-protocol bytes. A server that trusts its HTTP client may still receive third-party-controlled payload and expose parser bugs.
- Future token designs can consider forbidding optimistic transmission, a fixed preamble that terminates HTTP/1.1 parsing, or high-entropy masking. A familiar token name is not a security proof.
- If the method is irrelevant and the request needs no content, §7.1 says new tokens should restrict the method to GET without content. This is conditional lowercase design guidance, not a universal MUST for all transitions.
- HTTP/2 and HTTP/3 associate data with explicit streams instead of converting the whole TCP connection this way. RFC 9931 makes no IANA registrations.
This guide is a simplified security model, not a production proxy or a complete parser-conformance test. Implementers still need the linked HTTP and selected protocol specifications. Use the source links for the precise scope of each uppercase requirement.
Read the RFC section ↗