Visual RFC.
ALL RFCs / RFC 8297
Read the RFC ↗
RFC 8297 / FRAMING AND COMPATIBILITY

Preserve response boundaries and choose compatible clients

05

Misreading an informational response as final can associate later bytes with the wrong request. Servers can choose not to send 103 to HTTP/1.1 clients whose handling is uncertain.

DIAGRAMRead RFC section 3 ↗
RFC 8297 · § 3EXAMPLE
3 / 3
Preserve response boundaries and choose compatible clientsA correct HTTP1 parser keeps requestA pending through103, then completes it only at its final200. A separate conditional vulnerable example has a broken client closingA at103 and assigning the later finalA to requestB for another origin on a persistent proxy connection, risking cross-origin disclosure. The wrong assignment reachesB in this broken example; it is not shown as a successful defense. Last a server chooses a final-only response for uncertain HTTP1.1 handling, a permitted compatibility choice rather than a blanket prohibition. HTTP2 is less prone to this particular framing error, not universally risk-free.Correct boundaries before speculative speedHTTP/1.1 clientServerGET /pagefinal response onlyServer chooses not to send 103Client’s informational handling is uncertainNot a blanket prohibition of HTTP/1.1
03
Choose a compatible final-only exchange.

For an HTTP/1.1 client with uncertain informational handling, a server can omit 103 and send only the eventual final response. Early Hints are optional, not required for a successful request.

Source for this drawing: RFC 8297 · Read RFC section 3 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
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

RFC 9110 HTTP RFC 8288 Web Linking

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Do not trade correct response framing for a speculative speedup.

  • An HTTP/1.1 client mishandling 103 as final can misassociate subsequent responses. With requests for different origins on a persistent connection, that can cause cross-origin information disclosure.
  • RFC 8297 says a server might refrain from sending 103 over HTTP/1.1 unless the client is known to handle informational responses correctly. This is compatibility guidance, not a blanket MUST NOT for HTTP/1.1.
  • HTTP/2 clients are less likely to suffer this specific framing mistake because header handling does not determine the body end. This is not a claim that HTTP/2 removes all security risks. IANA registered code103 as Early Hints.
  • Current RFC 9110 §15.2 says a server MUST NOT send a 1xx response to an HTTP/1.0 client. The optional HTTP/1.1 compatibility choice is a different rule.
DETAILS

The vulnerable example is explicitly conditional: a broken client using a persistent proxy connection for multiple origins. It does not depict ordinary direct HTTP/1.1 connections as sharing unrelated origins automatically. No real requests, private bodies or exploits were used. 103 does not grant access, finish the request or mandate server push. The original memo referenced RFC 7540; current HTTP/2 is specified in RFC 9113.

Read the RFC section ↗

All chapters in RFC 8297

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗