RFC 10036

Incremental Forwarding of HTTP Messages

πŸ“… published August 2026, from ietf

RFC 10036: Incremental Forwarding of HTTP Messages πŸ’–

Okay bestie, this one is RFC 10036, called "Incremental Forwarding of HTTP Messages" ✨. The authors are K. Oku (Fastly), T. Pauly (Apple), and M. Thomson (Mozilla), so it's a whole all-star team πŸ‘‘. It's a Standards Track document from the Internet Engineering Task Force (IETF), which means it's an actual Internet standard and not just vibes πŸ’…. It's ISSN 2070-1721 and dated August 2026 πŸ—“οΈ. The title block doesn't list anything it obsoletes or updates, so it isn't replacing or changing any other RFC πŸ¦‹.

Abstract

So the whole point is this: the doc defines the "Incremental" HTTP header field, and that field tells HTTP intermediaries to forward the HTTP message incrementally πŸŽ€.

Status of This Memo

Okay this is the legal-but-important bit πŸ“œ. It's an Internet Standards Track document and a product of the IETF, so it represents the consensus of the IETF community 🫢. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841. For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc10036.

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. πŸ”’

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please read those carefully, because they spell out your rights and restrictions for this document. If you pull Code Components out of this document, you need to include the Revised BSD License text as described in Section 4.e of the Trust Legal Provisions. Those components come without warranty, as described in the Revised BSD License βš–οΈ.

Table of Contents

   1.  Introduction
   2.  Conventions and Definitions
   3.  The Incremental Header Field
   4.  Security Considerations
     4.1.  Permanent Rejection
     4.2.  Temporary Rejection
     4.3.  Handling of Small Packets
   5.  IANA Considerations
   6.  References
     6.1.  Normative References
     6.2.  Informative References
   Acknowledgments
   Authors' Addresses

1. Introduction ✨

Okay so HTTP [HTTP] lets receivers start processing parts of an HTTP message as they arrive, instead of waiting for the entire message to show up before doing anything πŸƒβ€β™€οΈ.

Some apps are built specifically to take advantage of that.

For example, Server-Sent Events [SSE] uses one long-running HTTP response, and the server keeps sending notifications as they become available πŸ””.

With Chunked Oblivious HTTP Messages [CHUNKED-OHTTP], the client opens an HTTP request and incrementally sends application data, while the server can start responding even before the request is fully complete. So the request-response pair could basically turn into a two-way communication channel 🀯.

Here's the catch. Apps that rely on incremental delivery are fragile when HTTP intermediaries are involved. That's because intermediaries aren't just allowed to buffer complete HTTP messages before forwarding them downstream, they're frequently deployed to do exactly that (Section 7.6 of [HTTP]) πŸ™ˆ.

If a buffering intermediary sits between the client and the server, these apps may not work the way they're supposed to πŸ’€.

With Server-Sent Events, an intermediary that tries to buffer the whole HTTP response before forwarding it could be left waiting forever. A client might never get any part of the response 😭.

With any bidirectional exchange, an intermediary that tries to buffer entire messages, whether requests or responses, stops any data from being delivered at all 🚫.

To help avoid this, the doc specifies the "Incremental" HTTP header field. It asks HTTP intermediaries to start forwarding the message downstream before they've received the complete message πŸ¦‹.

This indication might not be supported by intermediaries. Intermediaries that don't know about this field won't change their behavior. Intermediaries that do support the field might choose to reject a request instead; see Section 4 πŸ›‘οΈ.

2. Conventions and Definitions πŸ“š

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

This doc also relies on the structured field definitions of Item and Boolean [STRUCTURED-FIELDS] 🧩.

3. The Incremental Header Field πŸŽ€

Okay, the Incremental HTTP header field basically says what the sender wants intermediaries to do: start forwarding the message downstream before the entire message is received πŸ’š.

The Incremental header field is defined as a structured field [STRUCTURED-FIELDS] of type Item. Only Boolean values (Section 3.3.6 of [STRUCTURED-FIELDS]) are valid. If the field contains any other type, a recipient ignores it πŸ™…β€β™€οΈ.

Here's what the two values look like:

Incremental: ?1

A true value ("?1") means the sender is asking intermediaries to forward the message incrementally, as described below βœ….

Incremental: ?0

A false value ("?0") is the default behavior defined in [HTTP], where intermediaries might buffer the entire message before forwarding it. The explicit signal still helps, though, because it might give an intermediary more confidence to go ahead and buffer πŸ€·β€β™€οΈ.

The Incremental HTTP header field applies to each HTTP message on its own. So if both the HTTP request and the response need to be forwarded incrementally, the Incremental HTTP header field MUST be set for both the HTTP request and the response πŸ“¨πŸ“¨.

When a header section comes in with an Incremental header field that has a true value, HTTP intermediaries SHOULD NOT buffer the entire message before forwarding it. Instead, intermediaries SHOULD transmit the header section downstream and keep forwarding the bytes of the message content as they arrive ⚑. Since the Incremental header field only says how the message content should be forwarded, intermediaries can still buffer the entire header and trailer sections before forwarding them downstream 🧠.

If an intermediary decides flat-out to refuse forwarding the message body incrementally, it MUST generate an error response instead of buffering an entire message before forwarding it. Section 4 talks about the typical situations where an intermediary might refuse πŸ™….

The request to use incremental forwarding also applies to HTTP implementations. Most HTTP APIs let you transfer message content incrementally, but if one doesn't, for any reason, it SHOULD use the presence of the Incremental header field to reduce or disable buffering πŸ’….

The Incremental field might not be supported by intermediaries. Intermediaries that don't know about the field, or that don't support it, might buffer messages even when they've been explicitly asked not to. So clients and servers can't count on every intermediary to understand and respect a request to deliver messages incrementally 😬. Clients that depend on incremental forwarding can rely on prior knowledge or probe for support on individual resources πŸ”.

The Incremental header field helps set up a bidirectional byte channel over HTTP. Its presence in both requests and responses requests that intermediaries forward early responses (Section 7.5 of [HTTP]) and transmit message contents incrementally in both directions. That said, when you're developing bidirectional protocols over HTTP, Extended CONNECT [RFC8441][RFC9220] is generally more consistent with HTTP's architecture 🌈.

This document doesn't define any parameters for the Incremental header field value, but future documents might. Receivers MUST ignore unknown parameters 🫧.

6. References πŸ“šβœ¨

okay so here's the reading list, bestie πŸ’… the normative references are the big ones the spec leans on, and the informative ones are the extra context 🫢

6.1. Normative References

6.2. Informative References

Acknowledgments 🫢

The authors would like to thank many members of the IETF HTTP Working Group for their discussions and feedback on this specification. In particular, the authors would like to thank Mark Thomas, Piotr Sikora, Thibault Meunier, Marius Kleidl, Ben Schwartz, Willy Tarreau, Will Hawkins, Mark Nottingham, and Lucas Pardue for close review and suggested changes. the whole group is iconic πŸ‘‘

Authors' Addresses πŸ’Œ

  • Kazuho Oku
    • Fastly
    • Email: kazuhooku@gmail.com
    • Additional contact information:
      • ε₯₯ δΈ€η©‚
      • Fastly
  • Tommy Pauly
    • Apple
    • Email: tpauly@apple.com
  • Martin Thomson
    • Mozilla
    • Email: mt@lowentropy.net
πŸ“¦ where this page comes from