Re: Proposal: a new WRAP UP 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?
>
> 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
>
>
>