Re: Proposal: a new WRAP UP capsule

Lucas Pardue <lucas@lucaspardue.com> Tue, 09 July 2024 15:39 UTC

Resent-Date: Tue, 09 Jul 2024 15:38:39 +0000
Resent-Message-Id: <E1sRCvP-00DUkz-0f@mab.w3.org>
Received-SPF: pass (pan.w3.org: domain of lucaspardue.com designates 103.168.172.145 as permitted sender) client-ip=103.168.172.145; envelope-from=lucas@lucaspardue.com; helo=fout2-smtp.messagingengine.com;
Feedback-ID: i23b94938:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-568-g843fbadbe-fm-20240701.003-g843fbadb
MIME-Version: 1.0
Message-Id: <8ada24df-9941-4a37-b79b-8ef471c5459d@app.fastmail.com>
In-Reply-To: <SA1PR15MB4370BBF870827575AA1C05A8B3DF2@SA1PR15MB4370.namprd15.prod.outlook.com>
References: <CAPDSy+5UU=GSFWTdrkHW7RXNL8pr5KWtLfp8zjExsZvvGczfEw@mail.gmail.com> <SA1PR15MB4370BBF870827575AA1C05A8B3DF2@SA1PR15MB4370.namprd15.prod.outlook.com>
Date: Tue, 09 Jul 2024 16:38:07 +0100
From: Lucas Pardue <lucas@lucaspardue.com>
To: Ben Schwartz <bemasc@meta.com>, David Schinazi <dschinazi.ietf@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="d546def8646e417bb067fc347253c228"
Subject: Re: Proposal: a new WRAP UP capsule
Archived-At: <https://www.w3.org/mid/8ada24df-9941-4a37-b79b-8ef471c5459d@app.fastmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

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