Re: Proposal: a new WRAP UP capsule

David Schinazi <dschinazi.ietf@gmail.com> Tue, 09 July 2024 17:41 UTC

Resent-Date: Tue, 09 Jul 2024 17:40:05 +0000
Resent-Message-Id: <E1sREov-00Dq5M-2i@mab.w3.org>
Received-SPF: pass (pan.w3.org: domain of gmail.com designates 2a00:1450:4864:20::132 as permitted sender) client-ip=2a00:1450:4864:20::132; envelope-from=dschinazi.ietf@gmail.com; helo=mail-lf1-x132.google.com;
MIME-Version: 1.0
References: <CAPDSy+5UU=GSFWTdrkHW7RXNL8pr5KWtLfp8zjExsZvvGczfEw@mail.gmail.com> <SA1PR15MB4370BBF870827575AA1C05A8B3DF2@SA1PR15MB4370.namprd15.prod.outlook.com> <8ada24df-9941-4a37-b79b-8ef471c5459d@app.fastmail.com>
In-Reply-To: <8ada24df-9941-4a37-b79b-8ef471c5459d@app.fastmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Tue, 09 Jul 2024 10:39:47 -0700
Message-ID: <CAPDSy+6dg9BN7GfBi7RezHLim-cDOTJnusPaRNegcQQ=2KoT4g@mail.gmail.com>
To: Lucas Pardue <lucas@lucaspardue.com>
Cc: Ben Schwartz <bemasc@meta.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000bfe1be061cd40446"
Subject: Re: Proposal: a new WRAP UP capsule
Archived-At: <https://www.w3.org/mid/CAPDSy+6dg9BN7GfBi7RezHLim-cDOTJnusPaRNegcQQ=2KoT4g@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

Thanks all.

Regarding adding a signal to indicate client support, I agree with Lucas:
the policy will enforce a hard limit set by policy, no matter what the
client does. I don't think the proxy would change its behavior if it knew
whether the client supported this.

Regarding capsule vs h2/h3 frame, that's an interesting question.
Fundamentally, this signal is intended to flow from proxy to client - even
if it has to go through intermediaries between the proxy and client. If we
use an h2/h3 frame, we would have to define it such that intermediaries
need to understand it and forward it down the chain. We'd also lose h1
support. And intermediaries that use h1 on the back end aren't uncommon
these days. Because of these reasons, I think a capsule makes more sense.
That said, this does require the capsule protocol to be in play. I think
this ties in to the conversation we've been having around connect-tcp and
whether to use capsules there.

In terms of my token-limited use case, I think the best design for large
uploads/downloads is to use multiple separate proxied requests leveraging
range requests or resumable uploads. The alternate REFRESH_TOKEN design
would work too, but it has the downside of not working when the proxy is
going down for maintenance.

David

On Tue, Jul 9, 2024 at 8:38 AM Lucas Pardue <lucas@lucaspardue.com> wrote:

>
>
> On Sat, Jul 6, 2024, at 01:03, Ben Schwartz wrote:
>
> I think this is a reasonable idea.  Two questions come to mind:
>
> 1. Should this have a signal?  Right now there's no indication from the
> client about whether it supports this frame.  That makes it difficult for
> the server to understand whether the frame is working as intended.  Did I
> not give a long enough grace period, or are these clients running long
> because they don't recognize the capsule?
>
> I think the outcome is the same either way, a proxy can give a hint to a
> client using the capsule and it might not be able to do anything with it
> anyway even if understood. The proxy still needs to enforce its policy on
> when to shut the thing down.
>
>
>
> 2. Should this be a stream-scoped HTTP/2+3 frame type?  There are lots of
> cases of streaming requests and responses that might encounter some kind of
> limit in HTTP, including WebSocket, WebTransport, and even plain old POST
> and GET.  Should "this stream is getting too long for me" be a built-in
> function of HTTP?
>
> I'm not sure. I think it depends on the direction of nessage travel and
> what the limit applies to.
>
> One example we have is in resumable uploads, where we've defined an
> upload-limit header [1] that applies to resources, not streams. An upload
> can span multiple requests, and we indicate the limits of individual
> requests and aggregate size
>
> What single transaction cases would a frame help? For a large download,
> telling the client to wrap up isn't much good because it cant do anything,
> you could just reset the stream.
>
> WebSocket is a bidi pipe and similar to MASQUE flows., I could see wrap up
> applying there. The capsule seems like it would work too.
>
> [1]
> https://httpwg.org/http-extensions/draft-ietf-httpbis-resumable-upload.html#section-8.2
>
> --Ben
>
> ------------------------------
>
> *From:* David Schinazi <dschinazi.ietf@gmail.com>
> *Sent:* Friday, July 5, 2024 6:29 PM
> *To:* HTTP Working Group <ietf-http-wg@w3.org>
> *Subject:* Proposal: a new WRAP UP capsule
>
> Hi HTTP enthusiasts, Over in MASQUE land, as we're deploying our two-hop
> proxies, we decided we needed to put a cap on how many bytes we'd allow per
> token-authenticated connect-udp tunnel. Enforcing a hard limit is easy, but
> the issue
> ZjQcmQRYFpfptBannerStart
> This Message Is From an External Sender
>
>
> ZjQcmQRYFpfptBannerEnd
> Hi HTTP enthusiasts,
>
> Over in MASQUE land, as we're deploying our two-hop proxies, we decided we
> needed to put a cap on how many bytes we'd allow per token-authenticated
> connect-udp tunnel. Enforcing a hard limit is easy, but the issue is that
> if the proxy aborts the tunnel halfway through, the web browser could be
> halfway through a proxied request. Since the browser doesn't know if the
> half-finished request was acted on or not, it can't retry it, so it has to
> surface the error to the user. Instead, we want the proxy to be able to
> warn the browser that this will happen soon, so that the browser can
> establish a new tunnel with a new token, and start sending new requests
> there. Conceptually this is a little like GOAWAY, but instead of "please
> wrap up this connection", it's "please wrap up this tunnel stream". It uses
> capsules, since this is a message from proxy to client. Here's a draft with
> diagrams:
>
> https://datatracker.ietf.org/doc/draft-schinazi-httpbis-wrap-up/
>
> https://davidschinazi.github.io/draft-schinazi-httpbis-wrap-up/draft-schinazi-httpbis-wrap-up.html
>
> I'd love to hear your thoughts.
>
> Thanks,
> David
>
>
>

Proposal: a new WRAP UP capsule David Schinazi
Re: Proposal: a new WRAP UP capsule Martin Thomson
Re: Proposal: a new WRAP UP capsule Ben Schwartz
Re: Proposal: a new WRAP UP capsule Valentin Gosu
Re: Proposal: a new WRAP UP capsule Lucas Pardue
Re: Proposal: a new WRAP UP capsule David Schinazi
Re: Proposal: a new WRAP UP capsule Dustin Mitchell
Re: Proposal: a new WRAP UP capsule Ben Schwartz
Re: Proposal: a new WRAP UP capsule Lucas Pardue
Re: Proposal: a new WRAP UP capsule David Schinazi
Re: Proposal: a new WRAP UP capsule Tommy Pauly
Re: Proposal: a new WRAP UP capsule David Schinazi