Re: Working Group Last Call: Incremental HTTP Messages

Hi,

See response inline

On Fri, Oct 17, 2025, at 05:28, Kazuho Oku wrote:
> Marius, David, Ben, thank you for your responses regarding the handling of "Incremental: ?0".
> 
> I'm happy to see us confirming the consensus that we do not want to define a MUST-buffer mode.
Agree avoiding MUST here seems good.

> 
> 2025年10月17日(金) 11:02 Ben Schwartz <bemasc@meta.com>:
>> 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.
> 
> On this point, RFC 9110 allows intermediaries to buffer messages until they are complete [1].
> 
> Therefore, when the Incremental header is absent, incremental forwarding is not required; I read David’s comment as noting that, in that sense, defining `?0` may be moot—similarly to `Capsule-Protocol: ?0`.
> 
> That said, implementers might feel more confident if they could explicitly send `Incremental: ?0`. The trade-off, as Marius noted, is that it could also be read as potentially misleading. I’m curious whether providing that optional signal would do more good (by reducing guesswork) than harm.
> 

It seems we're getting ourselves knotted up on this because the design chose a value type that forces us to think in a binary way and use that term.

If instead the value was a token, where the only currently-defined terms were either `true` or `default`. Then it might be clearer that sending `default` or omitting the field are the same thing, and that default doesn't compelling an intermediary to do anything other than it already does.

It might be too late in the day to make such a change but figured I'd toss the idea out there because I see this pattern of misguided boolean usage a bit too much in my life.

Cheers 
Lucas

> [1] https://www.rfc-editor.org/rfc/rfc9110.html#section-7.6-5
>  
>>   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> 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> 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> 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$>
>>>> 
> 
> 
> --
> Kazuho Oku