Re: Proposal: a new WRAP UP capsule

Dustin Mitchell <djmitche@google.com> Tue, 09 July 2024 17:50 UTC

Resent-Date: Tue, 09 Jul 2024 17:49:31 +0000
Resent-Message-Id: <E1sREy3-00DspR-23@mab.w3.org>
Received-SPF: pass (puck.w3.org: domain of google.com designates 2607:f8b0:4864:20::62d as permitted sender) client-ip=2607:f8b0:4864:20::62d; envelope-from=djmitche@google.com; helo=mail-pl1-x62d.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: Dustin Mitchell <djmitche@google.com>
Date: Tue, 09 Jul 2024 13:48:16 -0400
Message-ID: <CALMtyTRYXp796P1AkpfEOF-VW-sW9xChuxFV7RpB=xu6Ky6xSQ@mail.gmail.com>
To: Lucas Pardue <lucas@lucaspardue.com>
Cc: Ben Schwartz <bemasc@meta.com>, David Schinazi <dschinazi.ietf@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000003a6438061cd42325"
Subject: Re: Proposal: a new WRAP UP capsule
Archived-At: <https://www.w3.org/mid/CALMtyTRYXp796P1AkpfEOF-VW-sW9xChuxFV7RpB=xu6Ky6xSQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

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

This seems not especially useful for requests and responses. A POST
request, for example, should fail if the server is unwilling to receive the
full-size body. It would be unusual for a client to be able to "wrap up"
mid-body. For more sophisticated uploads, the indicated other mechanisms to
adjust request size suffice.


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

This seems the class of usage that needs a "WRAP UP" -- a bidirectional
pipe that could otherwise continue indefinitely, can have traffic in-flight
at any time, and can be re-established without much trouble. Aside from the
use-case David described, "WRAP UP" might apply for websocket servers that
wish to shed idle or old connections without losing in-flight data. So
there's a use-case for this outside of proxies.

Capsule currently does not have any signalling characteristics. If we add
this one, will we be tempted to add more?

Dustin


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