Re: Fwd: New Version Notification for draft-kazuho-httpbis-incremental-http-00.txt

Guys, I just want to thank you for taking initiative on this work, and 
writing it up so clearly. It's a lovely enlightened solution for issues 
we face in subscriptions.

The issue is not just with intermediaries. Buffering happens within 
clients, as well. Firefox's fetch() implementation, for instance, 
buffers responses in the browser until they reach a particular size 
before letting your Javascript know that they exist. They can sit there 
forever, if new data does not come in. We currently work around this 
<https://github.com/braid-org/braidjs/issues/15#issuecomment-1069820315> 
in the Braid-HTTP polyfill by sending an extra half kB of blank lines 
with every pushed notification.

Three cheers,

Michael

On 10/15/24 6:35 AM, Kazuho Oku wrote:
> Hello folks,
>
> Tommy Pauly, Martin Thomson, and I have submitted a new I-D, titled 
> “Incremental HTTP Messages.”
>
> The draft can be found at the following locations, but please let me 
> introduce the draft.
> * https://datatracker.ietf.org/doc/draft-kazuho-httpbis-incremental-http/
> * 
> https://kazuho.github.io/draft-kazuho-httpbis-incremental-http/draft-kazuho-httpbis-incremental-http.html
>
>
> This draft defines the “Incremental” HTTP header field, which allows 
> senders of HTTP messages to request that intermediaries forward 
> portions of the HTTP message body as they arrive, instead of buffering 
> the entire message before forwarding.
>
> The goal is to reduce friction between endpoints running applications 
> that want incremental delivery and intermediaries that tend to buffer 
> messages.
>
> As you may know, several HTTP applications expect incremental 
> delivery, including those mentioned in the draft (Server-Sent Events 
> and Chunked OHTTP). These applications often don’t work as intended 
> when intermediaries are involved, as intermediaries frequently buffer 
> entire requests or responses before forwarding them downstream.
>
> It’s worth noting that intermediaries may have good reasons for this 
> behavior. For example, reverse proxies tend to buffer entire requests 
> [1] to reduce request concurrency on application servers behind them 
> (as a defense against the Slowloris attack).
>
> Currently, the only way to address this issue is by manually 
> configuring intermediaries to forward HTTP message bodies 
> incrementally - this must be done per intermediary instance, per 
> origin, or even per URI.
>
> This approach is tedious, unreliable, and doesn’t scale.
>
> Hence, our proposal.
>
> Endpoints sending HTTP messages can include the Incremental header 
> field to indicate that they want incremental delivery. Intermediaries 
> can check for this header and, if present, either forward the message 
> incrementally or reject it.
>
> Because the Incremental header field acts as a signal on a per-HTTP 
> message basis, intermediaries can still buffer ordinary HTTP messages 
> to minimize downstream concurrency, while forwarding messages 
> incrementally when requested.
>
> This way, we can eliminate the need for configuring intermediaries for 
> each deployment.
>
> In short, the introduction of the Incremental HTTP header field 
> eliminates the need of configuring intermediaries to support 
> incremental delivery, achieves better interoperability, and improves 
> security.
>
> We’d love to hear your thoughts. Thank you in advance.
>
> PS. The observations and opinions expressed in this email are my own 
> and haven’t been reviewed by my coauthors.
>
> [1] Nginx by default buffers the entire request; see 
> http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_request_buffering
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: 2024年10月15日(火) 21:32
> Subject: New Version Notification for 
> draft-kazuho-httpbis-incremental-http-00.txt
> To: 奥 一穂 <kazuhooku@gmail.com>, Martin Thomson <mt@lowentropy.net>, 
> Tommy Pauly <tpauly@apple.com>
>
>
> A new version of Internet-Draft 
> draft-kazuho-httpbis-incremental-http-00.txt
> has been successfully submitted by Kazuho Oku and posted to the
> IETF repository.
>
> Name:     draft-kazuho-httpbis-incremental-http
> Revision: 00
> Title:    Incremental HTTP Messages
> Date:     2024-10-15
> Group:    Individual Submission
> Pages:    6
> URL: 
> https://www.ietf.org/archive/id/draft-kazuho-httpbis-incremental-http-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-kazuho-httpbis-incremental-http/
> HTML: 
> https://www.ietf.org/archive/id/draft-kazuho-httpbis-incremental-http-00.html
> HTMLized: 
> https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-incremental-http
>
>
> Abstract:
>
>    This document specifies the "Incremental" HTTP header field, which
>    instructs HTTP intermediaries to forward the HTTP message
>    incrementally.
>
> Discussion Venues
>
>    This note is to be removed before publishing as an RFC.
>
>    Discussion of this document takes place on the HTTP Working Group
>    mailing list (ietf-http-wg@w3.org), which is archived at
> https://lists.w3.org/Archives/Public/ietf-http-wg/.
>
>    Source for this draft and an issue tracker can be found at
> https://github.com/kazuho/draft-kazuho-httpbis-incremental-http.
>
>
>
> The IETF Secretariat
>
>
>
>
> -- 
> Kazuho Oku