Re: Proposal: a new WRAP UP capsule

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://datatracker.ietf.org/doc/draft-schinazi-httpbis-wrap-up/>
https://davidschinazi.github.io/draft-schinazi-httpbis-wrap-up/draft-schinazi-httpbis-wrap-up.html<https://davidschinazi.github.io/draft-schinazi-httpbis-wrap-up/draft-schinazi-httpbis-wrap-up.html>

I'd love to hear your thoughts.

Thanks,
David