Resent-Date: Fri, 05 Jul 2024 22:29:57 +0000
Resent-Message-Id: <E1sPrRF-005Kin-2H@mab.w3.org>
Received-SPF: pass (puck.w3.org: domain of gmail.com designates 2a00:1450:4864:20::12d as permitted sender) client-ip=2a00:1450:4864:20::12d; envelope-from=dschinazi.ietf@gmail.com; helo=mail-lf1-x12d.google.com;
MIME-Version: 1.0
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Fri, 5 Jul 2024 15:29:36 -0700
Message-ID: <CAPDSy+5UU=GSFWTdrkHW7RXNL8pr5KWtLfp8zjExsZvvGczfEw@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000e23843061c87992a"
Subject: Proposal: a new WRAP UP capsule
Archived-At: <https://www.w3.org/mid/CAPDSy+5UU=GSFWTdrkHW7RXNL8pr5KWtLfp8zjExsZvvGczfEw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

--000000000000e23843061c87992a
Content-Type: text/plain; charset="UTF-8"

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

--000000000000e23843061c87992a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi HTTP enthusiasts,<div><br></div><div>Over in MASQUE lan=
d, as we&#39;re deploying our two-hop proxies, we decided we needed to put =
a cap on how many bytes we&#39;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&#39;t know if the half-finished=
 request was acted on or not, it can&#39;t retry it, so it has to surface t=
he error to the user. Instead, we want the proxy to be able to warn the bro=
wser that this will happen soon, so that the browser can establish a new tu=
nnel with a new token, and start sending new requests there. Conceptually t=
his is a little like GOAWAY, but instead of &quot;please wrap up this conne=
ction&quot;, it&#39;s &quot;please wrap up this tunnel stream&quot;. It use=
s capsules, since this is a message from proxy to client. Here&#39;s a draf=
t with diagrams:</div><div><br></div><div><a href=3D"https://datatracker.ie=
tf.org/doc/draft-schinazi-httpbis-wrap-up/">https://datatracker.ietf.org/do=
c/draft-schinazi-httpbis-wrap-up/</a><br></div><div><a href=3D"https://davi=
dschinazi.github.io/draft-schinazi-httpbis-wrap-up/draft-schinazi-httpbis-w=
rap-up.html">https://davidschinazi.github.io/draft-schinazi-httpbis-wrap-up=
/draft-schinazi-httpbis-wrap-up.html</a><br></div><div><br></div><div>I&#39=
;d love to hear your thoughts.</div><div><br></div><div>Thanks,</div><div>D=
avid</div></div>

--000000000000e23843061c87992a--