Re: Proposal: a new WRAP UP capsule

[David Schinazi <[e-mail]>]

The main use-case I have in mind is the one where the client sends
connect-udp to a proxy, and through that the client establishes an h3
connection to an origin, and then the client sends multiple proxied
requests to that origin. If the proxy needs to close this particular
connect-udp stream after some number of bytes exchanged, it'll first send
WRAP_UP to the client, so that the client can finish its in-flight proxied
requests to the origin, but not start any new proxied requests to the
origin.

David

On Tue, Jul 9, 2024 at 6:22 PM Tommy Pauly <[e-mail]> wrote:

>
>
> > On Jul 9, 2024, at 6:10 PM, Martin Thomson <[e-mail]> wrote:
> >
> > Hi David,
> >
> > I think that this is reasonable - if your goal is to suggest that
> clients terminate a single CONNECT flow, rather than the entire
> connection.  This could also be achieved with GOAWAY, but it will affect
> multiple flows.  The draft doesn't say this, so maybe I'm missing something
> important.
> >
> > How common is it to establish multiple flows through a single proxy?
> That might depend on use case (CONNECT-IP might be more profligate than
> CONNECT-UDP, say).
>
> I think you'd generally see the most for CONNECT-TCP and CONNECT-UDP, when
> you’re proxying an application like a web browser. CONNECT-IP would
> generally be much more limited, and in some cases just be a big VPN tunnel.
>
> Tommy
>
> >
> > Cheers,
> > Martin
> >
> > On Sat, Jul 6, 2024, at 08:29, David Schinazi wrote:
> >> 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
> >
>
>
>