Re: Proposal: a new WRAP UP capsule

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
>