Re: Proposal: a new WRAP UP capsule

Valentin Gosu <valentin.gosu@gmail.com> Tue, 09 July 2024 10:03 UTC

Resent-Date: Tue, 09 Jul 2024 10:02:48 +0000
Resent-Message-Id: <E1sR7gO-00CfeU-1w@mab.w3.org>
Received-SPF: pass (puck.w3.org: domain of gmail.com designates 2001:4860:4864:20::33 as permitted sender) client-ip=2001:4860:4864:20::33; envelope-from=valentin.gosu@gmail.com; helo=mail-oa1-x33.google.com;
MIME-Version: 1.0
References: <CAPDSy+5UU=GSFWTdrkHW7RXNL8pr5KWtLfp8zjExsZvvGczfEw@mail.gmail.com> <SA1PR15MB4370BBF870827575AA1C05A8B3DF2@SA1PR15MB4370.namprd15.prod.outlook.com>
In-Reply-To: <SA1PR15MB4370BBF870827575AA1C05A8B3DF2@SA1PR15MB4370.namprd15.prod.outlook.com>
From: Valentin Gosu <valentin.gosu@gmail.com>
Date: Tue, 09 Jul 2024 12:02:28 +0200
Message-ID: <CACQYfiJBWP61ar-_3u6BpbJYQHSW9-bJO3EcoS24RtB_VUoP2A@mail.gmail.com>
To: Ben Schwartz <bemasc@meta.com>
Cc: David Schinazi <dschinazi.ietf@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000515782061ccda17f"
Subject: Re: Proposal: a new WRAP UP capsule
Archived-At: <https://www.w3.org/mid/CACQYfiJBWP61ar-_3u6BpbJYQHSW9-bJO3EcoS24RtB_VUoP2A@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

Hi David,

I really like your proposal. As Ben noted, this sort of control plane
signaling would be useful for other kinds of HTTP tunnels.

I'm also interested in your use case - what happens if a user wants to
upload/download a very large resource through the tunnel without being
aborted?
Would a pay-as-you-go model be viable, where in response to a WRAP_UP
capsule the client responds with a REFRESH_TOKEN that extends the lifetime
of the tunnel?

--Valentin

On Sat, 6 Jul 2024 at 02:07, Ben Schwartz <bemasc@meta.com> 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?
>
> 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?
>
> --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