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

2024年10月15日(火) 20:47 Lucas Pardue <lucas@lucaspardue.com>:

>
>
> On Wed, Oct 16, 2024, at 04:24, Kazuho Oku wrote:
>
>
> 2024/10/15 19:30、Lucas Pardue <lucas@lucaspardue.com>のメール:
>
> 
>
>
> On Wed, Oct 16, 2024, at 00:51, Kazuho Oku wrote:
>
> Hello Lucas,
>
> Thank you for your comments.
>
> 2024年10月16日(水) 3:42 Lucas Pardue <lucas@lucaspardue.com>:
>
>
> Hi Kazuho,
>
> Interesting proposal, especially given some of the sharp edges.
>
> Specifically, the configuration of non-buffered message content and how
> proxies might operate, so let me respond to that bit in-line.
>
> Otherwise, I think the is a topic worth discussing in this venue.
>
> On Tue, Oct 15, 2024, at 14:35, 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.
>
> It's implicit in what you've said here but a intermediary platform (e.g. a
> CDN) likely has other config and DoS stuff going on that a single operator
> reverse proxy might not.
>
>
> Right.
>
> Intermediaries apply different policies for different types of requests.
>
> In HTTP, certain types of requests (e.g., websocket, CONNECT, masque) need
> incremental delivery. I believe that intermediaries that buffer request by
> default have exceptions for these types of requests. We do, at least.
>
> But the problem is that, for the applications that use ordinary vocabulary
> of HTTP (e.g., POST) and require incremental delivery, there is not a clear
> signal to the intermediary to deliver the request or response incrementally.
>
> Our proposal is to define a flag that indicates that, so that
> intermediaries can apply the same policy or logic for forwarding websocket,
> etc.
>
>
>
>
> 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.
>
>
> I looked for text on this topic in the I-D and couldn't find it.
>
>
> It is in the Security Considerations:
> https://kazuho.github.io/draft-kazuho-httpbis-incremental-http/draft-kazuho-httpbis-incremental-http.html#name-applying-concurrency-limits
> .
>
> Maybe it should be given its own section.
>
> I'm a little concerned that this where the design could unravel.
>
> Specifically two scenarios immediately come to mind
>
> 1) A client request includes Incremental. Proxy understands but wants to
> buffer for whatever reason. The operation is _improved_ by not buffering
> but can succeed without it. If a server *has* to reject this request,
> that's potential worse than today.
>
> 2) An origin response includes the Incremental header, Proxy understands
> but wants to buffer. Does it have to 5xx? This might be objectively worse
> than today especially if the origin already kicked off an expensive task.
>
> For these reasons, as much as i hate tk suggest complexity, I wonder if
> your proposal might not benefit from some additional indicators of
>
> a) how critical it is that Incremental be acted on - endpoints can suggest
> how they'd like a proxy to react
>
> b) whether the proxy supports Incremental for the specific resource. This
> presumes the proxy has made a decision already about what policy to apply.
> Then the origin could decide if it wants to bomb out serving or not.
>
>
> I agree.
>
> As you point out, buffering could be better than rejection for some
> applications. Resumable Uploads (as Marius points out) is one such example,
> that can use the flag for optimization.
>
> But for some applications that require incremental delivery (Chunked
> OHTTP), it it better to have a clear signal indicating that the
> intermediary cannot fulfill the requirements. We do not want to see human
> resources devoted to handling complaints of timeouts, just to find out that
> the application was in need for incremental delivery.
>
> Maybe the right thing to do is allow two values to be set in the
> Incremental header:
> * "Incremental: required" should be used by applications that prefer to
> see errors when intermediaries cannot provide incremental delivery.
> * "Incremental: preferred" should be used by applications that would
> benefit from incremental delivery but can operate without.
>
> WDYT?
>
> Yeah that's where I was headed in my head. But I think that only addresses
> one direction, where a client wants its request body to be forwarded
> incrementally.
>
> If a server needs its response body forwarded incrementally (and I'm aware
> of cases this is true), it can't be sure if the proxy would do that. So I
> was wondering if something like an "incremental-allowed: bool" request
> header could be defined that a proxy could send when it makes its policy
> decision. That way, an origin might stand a better chance of detecting a
> problem directly at source. Especially in a deployment where the proxy and
> origin have tighter integration expectations but worse logging cohesion.
>
>
> My thinking was that, if an intermediary refuses to incrementally forward
> an HTTP response with “Incremental: required”, the intermediary can send a
> 502 response to the client with a proxy-status header indicating the
> refusal.
>
> I do not have a strong opinion, but considering that the refusal for
> incremental delivery of requests are received by clients as 502 +
> proxy-status, it might make sense to signal thr refusal for responses the
> same way.
>
> That's certainly a possibility. I was just spitballing a bit that doing
> only that  might be undesirable because
>

Thank you for elaborating.


>
> a) the proxy can't signal with much fidelity to the origin why it aborted
> the response prematurely. This could get aliased with other connectivity or
> operational issues.
>

Yeah, my point is that because things can fail due to various reasons, and
because errors are often visible only to clients, we would see error
reports stating what the client saw.  If the client does not have the
capability to find out why things failed (including conditions like TCP
connection errors, 401, 404) then that's a much bigger problem that needs
to be fixed.


> b) the origin might have committed to doing work that it could have
> avoided. Not all jobs can be cancelled easily. An L7 load balancer could
> easily be setup with a blanket rule to reject requests that don't have the
> "i can do the thing u need" header, saving a more expensive call to a DB or
> 3rd party or whatever.
>
> c) avoiding entirely unavoidable work is good. My understanding of the
> motivation was to avoid needing brittle config, and to embrace in-band
> signalling so it can be more adaptive. Taking some of the decision making
> responsibility out of the proxy might make this easier to deploy.
>

I think these are good reasons, and it's not that difficult to design a
mechanism (like the one described by MT). Though, IMO it is more complex
compared to using the same header field for both request and responses.

I wonder if we can have input from developers that actually buffer the
entire response.

Anyways, I'm really happy that we seem to be discussing the solution, with
an agreement on requirements. That's a huge step.



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

-- 
Kazuho Oku