Existing tokens use different protections
06TLS, WebSocket, connect-udp and connect-ip already have different ways to avoid ambiguous optimistic data.
connect-ip already prohibits optimistic IP packets under HTTP/1.1. Its separate rule predates this update; RFC 9931 does not formally update RFC 9484.
Source for this drawing: RFC 9931 · Read RFC section 6.1 ↗
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.
Read the selected protocol’s own version-specific rule.
- TLS starts with byte 22 (handshake), which is invalid as the first HTTP method character. A compliant HTTP/1.1 parser treats it as an error and closes without processing more requests.
- WebSocket clients MUST wait for the server response before sending further data (RFC 6455 §4.1). High-entropy client-to-server masking is a separate protection against chosen wire patterns.
- The RFC 9298 update permits optimistic HTTP Datagram sending only in HTTP/2 or later: clients MAY do that there, but MUST NOT optimistically send UDP packets in HTTP/1.x.
- connect-ip already forbids optimistic IP packets with HTTP/1.1 (RFC 9484 §11). These distinct protections do not make arbitrary untrusted TCP bytes safe to send early.
Masking is not encryption. Invalid first bytes stop a compliant HTTP parser; they do not prove every alternative protocol implementation is free of parser bugs. The HTTP/2-or-later UDP permission still requires its protocol’s other rules.
Read the RFC section ↗