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

Hello Marius,

Thank you for your comments.

2024年10月16日(水) 2:03 Marius Kleidl <marius@transloadit.com>:

> Hello Kazuho,
>
> this is an interesting proposal, thank you for sharing it. Intermediaries
> buffering request bodies can cause problems with resumable uploads as well.
> When a request is aborted (e.g. due to connection issues), the intermediary
> would drop the partially received request instead of forwarding it to the
> server, who could save the partial request body for future resumption and
> avoid having to re-transmit the entire data. That's why we often recommend
> people to disable request buffering for resumable uploads. But as you
> mentioned, buffering does have its use cases and advantages. Having a more
> granular approach for opting out of message buffering appears useful.
>

That's a very good point. I agree that applications like Resumable Uploads
would also benefit from having the incremental signal.


>
> Best regards
> Marius Kleidl
>
> On Tue, Oct 15, 2024 at 3:37 PM Kazuho Oku <kazuhooku@gmail.com> 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
>>
>

-- 
Kazuho Oku