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 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://www.ietf.org/archive/id/draft-ietf-httpbis-incremental-01.html
>> >
>> > 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/
>> >
>> >
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>>
>>