Re: Working Group Last Call: Incremental HTTP Messages

I agree that a "must buffer" semantic is undesirable, but I would like to see "Incremental: ?0" mean "this message does not require incremental forwarding".

Currently, reverse proxies that I have worked with see a mix of messages that do and do not require incremental forwarding, with no clear indicator.  Labeling some as "Incremental: ?1" has little effect because the remainder are ambiguous, so all messages must be forwarded incrementally regardless of the header to ensure compatibility.

An explicit label for non-incremental messages could enable more efficient delivery by combining small writes, avoiding packets less than the MTU.  This is especially useful when forwarding between connections with slightly differing MTUs.
________________________________
From: David Schinazi <dschinazi.ietf@gmail.com>
Sent: Wednesday, October 15, 2025 10:02:15 PM
To: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Working Group Last Call: Incremental HTTP Messages

As someone who's currently dealing with trying to get chunked OHTTP to work through a buffering intermediary, I support this work moving forward. One small editorial nit: the term "downstream" was ambiguous to me, because in Envoy

As someone who's currently dealing with trying to get chunked OHTTP to work through a buffering intermediary, I support this work moving forward.

One small editorial nit: the term "downstream" was ambiguous to me, because in Envoy proxy terminology, "downstream" means "towards the client". I realize that this draft reuses the definition from 9110, but perhaps a reminder would help. Maybe something like: <<In this document, the term "downstream" uses the definition from Section 3.7 of RFC 9110".

On the topic of `Incremental: ?0`, I agree with Marius that we don't need to define that. Kazuho is right that `Capsule-Protocol` allows it, but it explicitly says "A Capsule-Protocol header field with a false value has the same semantics as when the header is not present." so the definition is pretty moot. We should either leave `Incremental: ?0` undefined or have it treated like an absent header. This draft shouldn't create "please buffer this message" semantics.

Cheers,
David

On Wed, Oct 15, 2025 at 12:30 PM Wenbo Zhu <wenboz@google.com<mailto:wenboz@google.com>> wrote:
The spec summarized the problem well, and also clarified the error statuses for proxies.

The main use case would be for response streaming. Our data shows up to ~3-5% of "hanging gets" are (still) buffered today.
I am not sure how effective such a header would be to address those intermediaries. I imagine (without knowing any concrete implementation) that they would choose to buffer everything or they would simply block any opaque payload such as application/octet-stream (or websockets for the same matter). For proxies that do inspect streamed content, they would proxy the HTTP body based on the actual C-T (e.g. SSE messages) which will be more effective.

The note on Connect for full-duplex bidi is very helpful (not sure if it's noted anywhere else). IMO, early response is a separate semantics, e.g. streamed content transcoding does "incremental" delivery for both request and response but otherwise it's simplex streaming.

Thanks,
Wenbo

On Tue, Oct 14, 2025 at 7:00 PM Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>> wrote:
Just a reminder, WGLC ends soon - please give your feedback (in particular, whether you support publication).

Cheers,


> On 28 Sep 2025, at 6:37 pm, Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>> wrote:
>
> Everyone,
>
> This email starts a working group last call for Incremental HTTP Messages.
>
> See:
>  https://datatracker.ietf.org/doc/draft-ietf-httpbis-incremental/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-httpbis-incremental/__;!!Bt8RZUm9aw!-mf6V81JrSLGJOY6UactBdWGnSC9gXvJ7YI0O_QbB59eYIfA-oFoUAW1E2h9gK3z5bw58QfAw4OecJKca5R2$>
>  https://www.ietf.org/archive/id/draft-ietf-httpbis-incremental-01.html<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-httpbis-incremental-01.html__;!!Bt8RZUm9aw!-mf6V81JrSLGJOY6UactBdWGnSC9gXvJ7YI0O_QbB59eYIfA-oFoUAW1E2h9gK3z5bw58QfAw4OecPvEgxHk$>
>
> Please send your review and comments in response to this email, and/or file issues to https://github.com/httpwg/http-extensions/issues.
>
> This call will be open for three weeks until Monday, 20 October, 2025.
>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/<https://urldefense.com/v3/__https://www.mnot.net/__;!!Bt8RZUm9aw!-mf6V81JrSLGJOY6UactBdWGnSC9gXvJ7YI0O_QbB59eYIfA-oFoUAW1E2h9gK3z5bw58QfAw4OecPBWYe8z$>
>
>

--
Mark Nottingham   https://www.mnot.net/<https://urldefense.com/v3/__https://www.mnot.net/__;!!Bt8RZUm9aw!-mf6V81JrSLGJOY6UactBdWGnSC9gXvJ7YI0O_QbB59eYIfA-oFoUAW1E2h9gK3z5bw58QfAw4OecPBWYe8z$>