Re: Working Group Last Call: Incremental HTTP Messages

I'm inclined to agree that the use of a Boolean may be, if not misguided,
then inflexible.

Conceptually there are multiple possible scenarios which this field could
specify for intermediary proxies:

must-not-buffer
must-buffer
should-buffer
should-not-buffer
may-buffer (field not passed)

where proxies would throw an error if they are unable to buffer a
must-buffer stream.

There could conceivably be more conceptual states, including relative
buffering priority of streams from the same server.

Would it make sense to use an extensible set of field values here, leaving
room to add in the future?

Rory

Rory Hewitt

http://www.linkedin.com/in/roryhewitt

On Fri, Oct 17, 2025, 2:49 AM Lucas Pardue <lucas@lucaspardue.com> wrote:

> 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
>
>
>