Re: Working Group Last Call: Incremental HTTP Messages

Lucas, Ben, Roy, Glenn, thank you for your comments.

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

I think I’m becoming convinced.

I’m sympathetic to the concern that `?0` might confuse people;
however, explicitly defining the meaning of `?0` could reduce
ambiguity. If a clear definition benefits some implementers, I’m
inclined to support it.

2025年10月17日(金) 18:44 Lucas Pardue <lucas@lucaspardue.com>:
> 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.

Yeah, we discussed if we need tri-state (i.e.,  incremental-required
vs. may-buffer vs. must-buffer) in
https://github.com/httpwg/http-extensions/issues/3041,  and decided
that we only need two modes.

Given that, use of a boolean fits and matches precedent (e.g.,
Capsule-Protocol; CDN-Cache-Control directives like private,
must-revalidate).

2025年10月18日(土) 3:27 Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>:
> Given the current (unspecified) case where some proxies do not buffer
> because they do not know the requirements, I would reduce the values
> minimally to:
> - must-not-buffer; incremental required
> - optional-buffering; incremental not required
>
> Instead of i, I would suggest r for required
> Incremental: r=?1  # incremental required
> Incremental: r=?0  # incremental optional; buffering optional
>
> and leave open for extension parameters in the list
> (which are hints and can be ignored)
>
> e.g. Incremental: r=?1, mtu=256  # w/ hint: max message size <= 256
>

As the values cleanly reduce to two modes, I'm concerned using a
dictionary adds avoidable complexity. Extensions are already possible
with the current syntax; for example, Incremental: ?1; mtu=256.


>
>
> Cheers, Glenn
>
> On Fri, Oct 17, 2025 at 09:32:18AM -0700, Rory Hewitt wrote:
> > 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
> > >
> > >
> > >



-- 
Kazuho Oku

Received on Monday, 20 October 2025 03:37:41 UTC