Incremental

The HTTP Incremental request and response header signals whether intermediaries like proxies and CDNs forward the message body incrementally as data arrives or buffer the complete message before forwarding.

Usage

Incremental addresses a long-standing gap in HTTP: intermediaries have no standard way to know whether a response is designed for incremental consumption. Without an explicit signal, proxies and CDNs make ad-hoc buffering decisions based on Content-Type sniffing, internal heuristics, or vendor-specific configuration. A CDN buffering a Server-Sent Events stream, for example, leaves the client waiting indefinitely for data the server already sent.

The header is a structured field of type Item, accepting Boolean values. A value of ?1 (true) tells intermediaries to begin forwarding the message body downstream as bytes arrive rather than accumulating the entire payload first. A value of ?0 (false) indicates the default HTTP behavior where intermediaries are free to buffer the complete message before forwarding.

The header applies per-message. When both the request and the response require incremental forwarding (for example, in bidirectional streaming protocols), both messages carry the header independently.

The header also applies to HTTP implementation libraries and frameworks. HTTP APIs providing buffered-only interfaces are expected to reduce or disable internal buffering when Incremental is present with a true value.

The problem before Incremental

Streaming over HTTP is common: Server-Sent Events, AI chat completions delivered token by token, live log tails, and chunked API responses all depend on the client receiving data as the server produces the data. These patterns work well on direct connections.

Intermediaries break the model. A reverse proxy buffering an SSE stream accumulates data in memory while the client sees nothing. A CDN buffering an LLM completion stream adds seconds of latency to every token batch. A content-inspection gateway waiting for a complete response body to scan blocks delivery of a response designed never to "complete" in the traditional sense.

Before Incremental, servers worked around these issues with vendor-specific headers (X-Accel-Buffering: no for Nginx), Content-Type detection heuristics (some CDNs disable buffering for text/event-stream), or configuration toggles per route. These approaches are fragile, non-portable, and invisible to the origin server.

Incremental provides a single, protocol-level signal the origin attaches to the response (or the client attaches to the request), expressing the sender's intent directly to every intermediary in the chain.

Values

?1

The ?1 value (Boolean true) requests incremental forwarding. Intermediaries receiving a header section with Incremental: ?1 forward the header section downstream and continuously transmit message body bytes as they arrive. The intermediary does not wait for the complete message.

Incremental: ?1

?0

The ?0 value (Boolean false) signals default HTTP behavior. Intermediaries are free to buffer the entire message before forwarding. Sending ?0 explicitly increases the intermediary's confidence in buffering, compared to omitting the header entirely.

Incremental: ?0

When the header is absent, intermediary behavior follows existing defaults: buffering is permitted and common.

Intermediary behavior

The core behavioral rules for intermediaries receiving Incremental: ?1 are straightforward:

• Forward headers promptly. Transmit the header section downstream without waiting for the body.
• Stream body bytes. Continuously forward message content as data arrives from the upstream connection.
• Buffering the header and trailer sections of the message remains acceptable. The incremental requirement applies to message content (the body), not metadata.
• Refuse rather than silently buffer. An intermediary deciding not to forward incrementally generates an error response rather than buffering the entire message and forwarding late.

Permanent rejection (501)

Content-inspection intermediaries examining the full message body for safety (malware scanning, data loss prevention) are incompatible with incremental delivery. These intermediaries respond with 501 (Not Implemented) and include an incremental_refused Proxy-Status value.

HTTP/1.1 501 Not Implemented
Proxy-Status: intermediary; error=incremental_refused

Temporary rejection (429)

Incremental forwarding ties up connection resources for the duration of the stream. Intermediaries imposing concurrency limits on forwarded requests apply stricter limits to incremental requests, preserving capacity for non-incremental traffic. When the limit is reached, the intermediary responds with 429 (Too Many Requests) and a connection_limit_reached Proxy-Status value.

HTTP/1.1 429 Too Many Requests
Proxy-Status: intermediary; error=connection_limit_reached

Small-packet buffering

Even with Incremental: ?1, intermediaries apply minimal buffering for efficiency. Forwarding every individual byte immediately wastes resources on many small packets. Intermediaries set byte-count or time-based thresholds to batch small writes. Once either threshold is reached, buffered data is flushed downstream. Data is never held indefinitely. The trade-off: small-packet buffering adds minor latency but prevents the intermediary from wasting resources on excessive per-byte forwarding.

Interaction with other headers

Transfer-Encoding

Transfer-Encoding: chunked is the HTTP/1.1 mechanism for sending a message body without a predetermined length. Incremental complements chunked rather than replacing the encoding. A chunked response tells the receiving node how to frame the data. Incremental tells intermediaries when to forward the framed data: immediately, as chunks arrive, or after the full body is received.

In HTTP/2 and HTTP/3, chunked transfer encoding does not exist. Data frames carry the payload natively. Incremental remains relevant in these protocols because intermediaries still choose whether to buffer data frames before forwarding.

Content-Length

The presence or absence of Content-Length does not conflict with Incremental. A response with both Content-Length: 50000 and Incremental: ?1 is valid: the intermediary knows the total size but still forwards bytes as they arrive rather than waiting for all 50,000 bytes. Responses of unknown length (no Content-Length, chunked encoding) are the more common pairing with Incremental: ?1, but the header works with either pattern.

Content-Type

Incremental is content-type agnostic. Any Content-Type pairs with the header. Common streaming types like text/event-stream (Server-Sent Events) and application/json (AI completion streams using chunked JSON) benefit the most, but progressive image delivery (image/jpeg with progressive encoding) and live log output (text/plain) are equally valid.

Cache-Control

Streaming responses are typically not cacheable. Pairing Incremental: ?1 with Cache-Control: no-store or no-cache prevents intermediaries from attempting to cache a response meaningful only in real time. For cacheable resources delivered incrementally (rare but possible), standard caching semantics apply. The Incremental header does not override or interact with caching directives.

Bidirectional streaming and Extended CONNECT

Setting Incremental on both the request and the response enables a bidirectional byte channel over standard HTTP request-response pairs. The client sends body data incrementally while the server responds incrementally, creating an effect similar to a persistent duplex connection. For new bidirectional protocol designs, the Extended CONNECT mechanism (used by WebSockets over HTTP/2 and HTTP/3) provides a more architecturally consistent approach. Incremental serves as an alternative when Extended CONNECT is unavailable or the use case fits naturally into the request-response model.

Example

An AI chat completion endpoint streaming tokens as Server-Sent Events. The server signals incremental delivery so intermediaries forward each event as the event is generated rather than buffering the entire stream.

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache
Transfer-Encoding: chunked
Incremental: ?1

data: {"token": "The"}

data: {"token": " capital"}

data: {"token": " of"}

data: {"token": " France"}

data: {"token": " is"}

data: {"token": " Paris"}

data: [DONE]

An AI completion response using chunked JSON delivery over HTTP/1.1. Each chunk carries a partial response object. The Incremental: ?1 header ensures proxies between the API server and the client forward chunks on arrival.

POST /v1/completions HTTP/1.1
Host: api.example.re
Content-Type: application/json
Incremental: ?1

{"model": "gpt-4", "prompt": "Explain HTTP", "stream": true}

HTTP/1.1 200 OK
Content-Type: application/json
Transfer-Encoding: chunked
Incremental: ?1

{"choices":[{"delta":{"content":"HTTP"}}]}
{"choices":[{"delta":{"content":" stands"}}]}
{"choices":[{"delta":{"content":" for"}}]}
{"choices":[{"delta":{"content":" Hypertext"}}]}

A non-incremental response for a complete file download. The explicit ?0 increases the intermediary's confidence in buffering the full response before forwarding, which is appropriate for a resource where partial delivery has no value.

HTTP/1.1 200 OK
Content-Type: application/gzip
Content-Length: 2048576
Content-Disposition: attachment; filename="backup.tar.gz"
Incremental: ?0

A reverse proxy rejecting an incremental request because the proxy performs content inspection on all forwarded traffic. The Proxy-Status header communicates the reason.

HTTP/1.1 501 Not Implemented
Proxy-Status: cdn.example.re; error=incremental_refused
Content-Type: text/plain

Incremental forwarding is not supported.
This proxy requires full message inspection.

A reverse proxy rejecting an incremental request because the proxy has reached the concurrent incremental stream limit. The client retries after the period indicated by Retry-After.

HTTP/1.1 429 Too Many Requests
Proxy-Status: cdn.example.re; error=connection_limit_reached
Retry-After: 5
Content-Type: text/plain

Too many concurrent incremental streams.

Takeaway

The Incremental header provides a dedicated signal for controlling intermediary buffering behavior. Setting ?1 tells proxies and CDNs to forward response (or request) data as bytes arrive, enabling reliable streaming for Server-Sent Events, AI completions, live logs, and other latency-sensitive applications depending on incremental delivery through the HTTP chain.

See also

• Incremental Forwarding of HTTP Messages (draft-ietf-httpbis-incremental)
• HTTP Semantics (RFC 9110)
• The Proxy-Status HTTP Response Header Field (RFC 9209)
• Structured Field Values for HTTP (RFC 9651)
• Structured Fields
• Transfer-Encoding
• Content-Encoding
• Content-Length
• Content-Type
• Cache-Control
• Proxy-Status
• Streaming
• HTTP headers