Re: Working Group Last Call: Incremental HTTP Messages

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