Re: Working Group Last Call: Incremental HTTP Messages

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.

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.

[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