Summary

  • RFC 10036 defines Incremental: ?1 as a sender's per-message request that intermediaries forward content before receiving the whole message. Request and response are separate: both need the field when both directions need incremental delivery.
  • A hop that understands the field and outright refuses incremental body forwarding must return an error rather than silently buffer. The recommended contexts distinguish a durable inspection incompatibility—501 plus incremental_refused—from temporary concurrency pressure—429 plus connection_limit_reached.
  • This is not an end-to-end streaming promise. An unaware or non-supporting hop may ignore the field and buffer, while a supporting hop may use bounded byte- or time-based buffering. Proof therefore needs a path-to-outcome receipt, not a screenshot of one header.

The difficult failure is not always a connection that closes. Sometimes a request remains open, the server begins responding, and nothing useful reaches the client. The intermediary is waiting for an entire body. The application is waiting for the intermediary. Every component still appears alive.

That failure is especially severe when the exchange is bidirectional. A client may produce a request body over time while the server sends useful response data before the request finishes. If a hop waits for the complete request or the complete response, neither side receives the bytes it needs to continue. The apparent optimisation becomes a deadlock at application level.

RFC 10036, Incremental Forwarding of HTTP Messages, gives this problem a deliberately small signal. Published as an IETF Proposed Standard in August 2026, it names Kazuho Oku, Tommy Pauly and Martin Thomson as authors. It does not replace HTTP, invent a universal streaming mode or compel intermediaries that do not understand it. It lets a sender state an intent, and it makes one class of refusal explicit at a participating hop.

Oku's public record supplies useful context without turning the standard into a personal possession. The IETF Datatracker profile captured on 31 August 2026 lists four RFCs, including RFC 10036, Early Hints in RFC 8297, HTTP Extensible Priorities in RFC 9218 and a further HTTP-related RFC. Fastly's first-party author page describes him as a Principal OSS Engineer and the author of H2O, quicly and picoTLS. Those facts establish sustained work on high-performance Internet software. RFC 10036 remains collective IETF work, and each deployed path remains under its own operators' control.

The header asks; the path decides

Incremental is a Structured Fields Item. Only a Boolean is valid. A recipient ignores the field if the value has another type. ?1 asks intermediaries to begin forwarding the message before receiving all of it; ?0 expresses the ordinary case in which an intermediary may buffer the entire message and may give the hop greater confidence in doing so.

The message boundary matters. HTTP request and response are separate messages. A client that marks its request ?1 has not marked the response. A server that wants its response forwarded incrementally must add the field to that response. A bidirectional application needs the signal in both directions.

That is more than syntax. It prevents a vague claim such as “this endpoint supports streaming” from hiding which direction was tested. An upload may flow through while an early response remains trapped. A response stream may arrive promptly while the request body is still accumulated upstream. A useful receipt names the message and direction before it names the result.

When a supporting intermediary receives ?1, RFC 10036 says it should not buffer the entire body. It should transmit the header section downstream and continuously forward content bytes as they arrive. Header and trailer sections can still be buffered in full because the field governs message content, not every section of the HTTP message.

The signal is therefore an instruction about forwarding behaviour at a capable hop, not a new transport. It can facilitate a bidirectional byte channel when both messages carry it, but the RFC notes that Extended CONNECT is generally more consistent with HTTP architecture for bidirectional protocols. Choosing the field does not erase the engineering question of whether the application should use a different protocol shape.

Refusal becomes an observable branch

The strongest sentence in the RFC concerns a hop that understands the request and makes a deliberate decision against it. If that intermediary outright refuses to forward the body incrementally, it must generate an error response rather than buffer the complete message and later forward it.

That rule protects the application from false success. Silent buffering can satisfy conventional HTTP semantics while destroying the timing property on which the application depends. The request may eventually complete, yet the user experiences a frozen console, a delayed model response, an unusable event feed or a control channel that never becomes interactive. A clear error allows the endpoint to choose a fallback, retry elsewhere, use another protocol or explain that the operation is unavailable.

The obligation is narrow. It applies when the intermediary understands Incremental and decides outright to refuse incremental body forwarding. It does not say that any observed delay is a refusal, nor that a hop must forward each byte immediately. That boundary is what makes the result useful: an explicit branch means a participating policy was exercised; silence remains ambiguous.

Running-Code Primacy turns this distinction into a test. Send a controlled response in identifiable chunks through the real production path. Record when each participating hop receives and forwards the first and last bytes. Exercise the refusal condition. Confirm that the intended status and proxy context reach the endpoint. A design document saying “streaming enabled” is not equivalent evidence.

Two errors describe two operating constraints

RFC 10036 describes two common reasons for a deliberate refusal.

The first is structural. Some intermediaries inspect a complete message and forward it only after judging the contents safe. A function that requires the entire body is incompatible with incremental delivery. When security concerns prevent incremental forwarding, the intermediary should respond with 501 Not Implemented and attach an incremental_refused Proxy-Status error.

That outcome says the path cannot provide the requested property under its current inspection policy. Repeating the same request later is unlikely to change the result unless the route, resource or policy changes. The remediation is architectural: select a compatible route, change the inspection model, move the sensitive exchange, or use a protocol that the intermediary can handle without full-message buffering.

The second reason is temporary capacity. Intermediaries often cap the number of requests or connections they forward concurrently and buffer excess work. Because an incremental exchange can occupy resources for longer, a hop may assign it a tighter concurrency pool to preserve service for ordinary requests. On reaching that limit, the RFC says the intermediary should respond with 429 Too Many Requests plus connection_limit_reached in Proxy-Status.

That outcome supports a different response. The resource may be compatible, while capacity is currently unavailable. Backoff, admission control, priority, a larger pool or a controlled fallback might help. Collapsing both cases into “streaming failed” would lose the operational distinction the standard was designed to expose.

Status alone is insufficient. A 501 can arise for reasons unrelated to incremental delivery, and a 429 can reflect many rate limits. The joined evidence includes Proxy-Status, the responsible hop, resource identity, policy version and time. Conversely, Proxy-Status is only as complete as participating intermediaries make it; it is not a magical census of every device on the path.

The unsupported hop is the blind spot

The essential limit follows immediately from HTTP extensibility. An intermediary that does not know the field will not change its behaviour. A hop that knows of the field but does not support it may also buffer despite the sender's request. RFC 10036 therefore says clients and servers cannot expect all intermediaries to understand and respect ?1.

This is why “no error” does not prove support. A participating hop that rejects has become visible. An unaware hop can remain silent while retaining the whole body. The same client trace can show the field leaving and the response eventually arriving without revealing where the latency was introduced.

Prior knowledge can narrow the uncertainty. An operator may control every hop on a fixed service path and maintain a tested capability record. Otherwise the RFC suggests probing support on individual resources. Resource specificity matters because one hostname can traverse different policies by path, geography, customer class, body type or traffic condition. A successful probe is evidence for the path conditions under which it ran, not a permanent certification of a brand.

The agency boundary is precise. The sender expresses a preference. Each intermediary owns its forwarding, security and capacity decisions. The receiving endpoint interprets the outcome. A field cannot exercise authority over software that does not understand it, and one endpoint cannot grant conformance on behalf of an entire chain.

Small buffers still move the latency outcome

Even a supporting intermediary may buffer a small amount for efficiency. Forwarding every tiny packet immediately can waste work and create an abuse surface. RFC 10036 therefore permits byte and time thresholds. Data must be forwarded when either limit is reached; it cannot be held indefinitely.

This bounded discretion is operationally important. Two implementations can both support the field and still deliver materially different first-byte latency. A five-kilobyte threshold may be invisible for a rapid response and damaging for a low-volume event stream. A short timer may be acceptable for human-facing output and too slow for a feedback control loop. “Supported” is a necessary classification, not an application SLO.

Operators should retain the policy value that produced the result. A latency incident cannot be reconstructed from the field and final status alone. It needs the hop's buffer threshold, occupancy, scheduling class and receive/forward timestamps. When the policy changes, probes must be repeated because the same software version may now deliver a different experience.

Minimum Initial Specification provides a useful restraint. The shared standard should define the smallest interoperable signal and visible refusal behaviour. Local operators should publish or retain the resource eligibility, thresholds, concurrency budgets, inspection constraints and fallback rules needed for their environments. Turning those local choices into a universal mandate would make the field less deployable, not more reliable.

Build the path-to-outcome receipt

Start with identity: client and server build, resource, request identifier and whether the observation concerns the request or the response. Preserve the exact field value and whether it passed Structured Fields Boolean parsing. Record which component set it and why the application depended on incremental delivery.

Then map the path that is actually knowable. For each controlled or participating intermediary, retain protocol segment, recognition/support status, content-inspection rule, body/header/trailer policy, byte and time thresholds, concurrency pool, occupancy and priority class. Prior knowledge needs an owner and an expiry; otherwise yesterday's capability statement becomes today's assumption.

Join the outcome. Keep HTTP status, complete Proxy-Status member, proxy error type and responsible hop. Measure first byte received and forwarded, last byte received and forwarded, and the application's latency or stall result. Record whether the exchange was accepted, degraded by bounded buffering, rejected structurally, refused temporarily, silently buffered at an unknown point or left inconclusive.

Finally, retain the decision: fallback, retry, route change, protocol change, capacity action, security exception, operator and remediation. Avoid storing sensitive bodies merely to prove timing. Correlation-safe identifiers, policy versions and timestamps can show the authority chain without turning observability into a content archive.

The receipt should be able to disprove its own conclusion. If a hop is unknown, say so. If a probe covered only a response, do not infer request behaviour. If Proxy-Status was stripped, preserve that gap. Trust improves when uncertainty has a field instead of being converted into a green badge.

Sources