Summary

  • RFC 10036 defines the Boolean Incremental HTTP field. A true value asks intermediaries to forward content as it arrives rather than wait for the entire message; an aware intermediary that refuses outright must return an error instead of silently whole-message buffering.
  • The field is not a capability handshake or delivery receipt. An unaware intermediary can ignore it, both request and response need their own signal, and bounded byte or time buffering remains permitted. First-event movement must still be observed hop by hop.

A correct instruction can disappear at the next hop

The endless event stream in the opening exposes the difference between a local handling rule and an end-to-end outcome. The first proxy has enough information to choose its incremental mode. The second does not recognize the field and applies ordinary HTTP behavior. Because ordinary intermediaries are allowed to buffer complete messages, the second proxy can wait forever without violating a rule it does not know.

There is no positive acknowledgement in RFC 10036 that every intermediary understood the request. Seeing the field leave the origin proves only that the sender expressed an intent. Seeing early bytes leave one proxy proves only that hop. A 200 response does not prove that the first content byte reached the user, especially when the response itself may have begun before an upload finished.

This is not the same authority question as HTTP Priority. A priority signal helps a scheduler decide which eligible bytes to serve first under contention. Incremental asks whether a message should start crossing a hop before its last byte arrives. A server can honor one and not the other. A path can stream incrementally while allocating few resources, or assign high priority while a later intermediary still waits for message completion.

RFC 10036 creates a narrow forwarding contract

The RFC Editor published RFC 10036 as an IETF Standards Track document in August 2026. The work came through the HTTP Working Group. IANA now lists Incremental as a permanent HTTP field with Structured Field type Item and lists incremental_refused as an HTTP Proxy Error Type.

The valid field value is a Structured Field Boolean. ?1 requests incremental forwarding. ?0 says the default behavior applies and can give an intermediary greater confidence that full-message buffering is acceptable. A value of another type is ignored. Future parameters can be added, but an unknown parameter is ignored rather than turning the whole Boolean into a negotiation protocol.

The scope is one HTTP message. If an application requires an upload to move while a response also moves, the request and response each need the true value. A request field does not confer incremental behavior on the response, and a response field does not rewrite how the request body was handled.

For an aware intermediary that accepts the request, the contract is meaningful: it should send the header section and continuously forward content bytes as they arrive, rather than buffer the entire content. The intermediary can still collect the complete header or trailer section. The field governs content-forwarding mode, not all processing boundaries.

Explicit refusal is evidence, not failure of the design

Some security functions need the complete message before deciding whether it is safe. That requirement is incompatible with forwarding early content. RFC 10036 does not grant the sender authority to disable inspection. It gives an aware intermediary a more honest choice: forward incrementally or reject instead of accepting and then silently waiting for the whole body.

For a permanent inability to forward because of content-security policy, the RFC recommends a 501 response accompanied by Proxy-Status error incremental_refused. That pair turns an invisible stall into a classified refusal. It lets an operator separate “this function cannot work incrementally here” from origin latency or transport loss.

Capacity can produce a different refusal. Long-lived incremental requests consume concurrency and connection state. An intermediary may impose a tighter limit on them to preserve availability for other traffic. When that limit is reached, RFC 10036 recommends 429 with Proxy-Status connection_limit_reached.

Neither status is permission to guess at the whole path. Proxy-Status members are produced by intermediaries, can omit details to protect internal topology and may be stripped. Trailer fields can disappear. The diagnostic record needs the identity of the reporting hop, the policy and capacity state that applied, and corroborating local telemetry.

Incremental does not mean zero buffer

Forwarding every tiny arrival as a separate packet or write can waste CPU, bandwidth and downstream work. The RFC therefore permits a small amount of buffering even for incremental content. An implementation can release data when a byte threshold or time threshold is reached.

This bounded coalescing is not whole-message buffering. The operational distinction is whether progress has a finite, declared limit independent of message completion. A 16-kilobyte threshold and a 20-millisecond timer produce a measurable latency envelope. “Wait until the body ends” does not, particularly for a stream that may run for hours.

A sender cannot infer the thresholds from ?1. Nor does the field demand immediate packet emission, bypass flow control, override congestion control or reserve bandwidth. HTTP libraries, proxies, TLS stacks, kernels and transport paths may each introduce a delay after the application chooses its mode.

The useful service objective is therefore not “buffering disabled.” It is a distribution of time and bytes from arrival on one side of a hop to first and continuing egress on the other, under specified message sizes, event cadence, concurrent load and failure conditions.

An unaware intermediary is the hard boundary

An intermediary that understands the field must reject if it decides outright not to honor the requested mode. An intermediary that does not understand it cannot follow that rule. It may ignore the field and buffer exactly as it did before RFC 10036.

That asymmetry is why the specification points applications toward prior knowledge or resource-specific probing. The field is a coordination signal for compatible implementations, not universal capability discovery. A successful probe on one URL, POP, protocol version or route is not permanent evidence for another.

Paths change. A CDN can add a security layer, split traffic between software generations, move a tenant to another gateway or negotiate a different HTTP version upstream. A canary that measures only origin-to-edge behavior can miss an edge-to-client buffer. A synthetic client that finishes a small response can miss the indefinite-wait failure of a real stream.

Capability evidence therefore needs a path and a time. Record DNS and routing selection, proxy identities, HTTP versions, configuration revisions, header preservation, buffer thresholds, first-header and first-content timestamps, continuing cadence and the client observation. Repeat after topology and policy changes.

Long-running and bidirectional uses expose different risks

Server-Sent Events is the clearest response-side case because it turns whole-message buffering into an indefinite wait. The application should test that events emerge at their expected cadence through every supported production path, not merely that the response headers arrived.

Chunked Oblivious HTTP motivates both directions: a client can continue sending application data while a server begins responding. Both messages require their own signal. The IESG writeup notes that the incremental field is a dependency of that work and also reports few live implementations of the header. That is a warning to measure support, not a reason to weaken the standard's semantics.

RFC 10036 also says Extended CONNECT is generally more consistent with HTTP architecture for bidirectional protocols. HTTP/2 and HTTP/3 define Extended CONNECT mechanisms for WebSockets. Choosing an ordinary request-response exchange with incremental content should be an explicit compatibility decision, not an assumption that one new field converts every proxy path into a generic tunnel.

Preserve the chain from intent to observed progress

The sender owns the intent it places on a message. Each intermediary owns its support, inspection policy, capacity limit and buffering thresholds. The application owner decides whether the observed path is adequate for the product and what fallback is safe.

The evidence chain begins with message identity and direction, exact Boolean parsing and every hop's software and configuration. It continues through field propagation, local handling mode, byte and time thresholds, ingress and egress timestamps, refusal status and trusted Proxy-Status. It ends with the client's first event, continuing cadence, application state and resource impact.

Do not promote the first layer into the last. A registered field does not prove support. Support does not prove this request used it. One-hop egress does not prove end-to-end delivery. First-byte delivery does not prove safe continuing service. The new standard makes a hidden policy choice expressible. Running evidence must show where the bytes went.

Sources