Re: Proposal: a new WRAP UP capsule

Ben Schwartz <bemasc@meta.com> Tue, 09 July 2024 19:38 UTC

Resent-Date: Tue, 09 Jul 2024 19:37:48 +0000
Resent-Message-Id: <E1sRGeq-00E91j-2G@mab.w3.org>
Received-SPF: pass (pan.w3.org: domain of meta.com designates 67.231.153.30 as permitted sender) client-ip=67.231.153.30; envelope-from=prvs=29208bb8aa=bemasc@meta.com; helo=mx0a-00082601.pphosted.com;
From: Ben Schwartz <bemasc@meta.com>
To: David Schinazi <dschinazi.ietf@gmail.com>, Lucas Pardue <lucas@lucaspardue.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Thread-Topic: Proposal: a new WRAP UP capsule
Thread-Index: AQHazysuucqou3ybt0aCTuDQql0chbHoz4JBgAW+JYCAACH+gIAAFmvx
Date: Tue, 09 Jul 2024 19:37:36 +0000
Message-ID: <SA1PR15MB43706FB732C8F277D7FE4E78B3DB2@SA1PR15MB4370.namprd15.prod.outlook.com>
References: <CAPDSy+5UU=GSFWTdrkHW7RXNL8pr5KWtLfp8zjExsZvvGczfEw@mail.gmail.com> <SA1PR15MB4370BBF870827575AA1C05A8B3DF2@SA1PR15MB4370.namprd15.prod.outlook.com> <8ada24df-9941-4a37-b79b-8ef471c5459d@app.fastmail.com> <CAPDSy+6dg9BN7GfBi7RezHLim-cDOTJnusPaRNegcQQ=2KoT4g@mail.gmail.com>
In-Reply-To: <CAPDSy+6dg9BN7GfBi7RezHLim-cDOTJnusPaRNegcQQ=2KoT4g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
msip_labels:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SA1PR15MB4370:EE_|BY3PR15MB4947:EE_
x-ms-office365-filtering-correlation-id: 8d28bd27-2f20-44fc-d10e-08dca04e95ee
x-fb-source: Internal
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|3613699012|38070700018;
x-microsoft-antispam-message-info: xOk3CY2bg8aeQL9+s8JWSSu042bQQFzZtIqKlwmNW1bHZXLWaR+2AzNCaXf3eMLL2sCRBLjSJpcIa0bL7e2crMys4Xsbbz6F8L+KBepGr04CzMYimgfNn6nx89HXUi09yrzQGIeDpz4/9ybeI4PF5Polaf0dSU/HHovyPB3xoh+c2ply+J29WJr/u9VEqQCu+RWYQBG14aD2fCbKKn4R6cPTQs8iRE2aImkcyXyffNGr1ZEDMd28Fr9Q5nFQQzCcvfAcdOqor0gDSzY8SBfjubjiAEP+xqTvXqc/8pyyDOn8xygisT5not2PqQAERo7dHS4X2HrRYYfaovAMuY70mOGJ/In/lldXKeH57UU5QXV25L0O1g7ng5YUAc1KNuJNJkZz/9cimNQTJNbCwbYzG8NQQQtLlianmvXM1ro5kHbYVryx8e8mpXO3tJvqaQaTvygUfR1OeCj9cuTnkviRWm/CZLRrdU4yAyOfbRS3bo8PA4Aumk/JZHuRXJR/Rve3zmjeCR0LKhe07YQsuLSXZ3xpQNrRoB9Rc51ly1yBROj+1+/dLcfH1aF+kNVAD6A0NU5A1O3GcWYx6+P64tw8jp4IZe4OHCz0VyyxZxDdTlIasB7mYLkXd82vS8yiwZJhtrxaM2tvflOf7Y3LHKb6U4VWEWNwJbU7uEsLipKyyF7MUoL3cYhbEOWeBGxAfv43PIRHkLiXx/KBIz2Wf3dkZ8tSEcV5ycrb2/JNMZUQ+HpE3PSvb0jddaQ+2Th6Mses+23hj8uU7ilgx/PbYGiSfvhwZ+umIC0ihWzn2nm1DnLdrT5fKPa14RWadLkkSQHi2Mtkz0HrsGytXR6mG08XqpYeA/ZCz7I3rwzyphnGhvEysIoqIjGGn4Tmd57k24NZgB6PSV5uBiepveTFRgLKBqpFlkF/36tLZqR3Idqndt6SzKLy7QWsQ05rAJuaAIQfoUHHtKm63efu79as6Z3Ey/sNWxBXD9cnXKD2BI1KbQ1iwcBrGWZVXLGdyUtiSwxFUAISiLv605bYsqDZL+GWwroX51s55mjgYwSvrxTKLQqUxqornKr6ZSCVkG/Q9GkaEMGpQLuvb5J4HLbGUdNtKZkbe5rm0419aV9j1WVaumXprKIZEyhGqvfndLZuaxsTIZ7Ss89ikj84CZYECU5+uZ1V27BpXfJf2Vb2pcVNdOLuInRnim+RslsJ09RcfOenW2Wsvwm4iyAUsk7+ZoOVtEevh4yn1NWhPWGGtBLJQ+FLOGjbjc90lxArPBKapoiW8N5z/WYnbgLp5pnzLWZVEsOKCvkVFdI9NEp7GOa/NEfYEvfteqglB0Uu9kQHSHH9/nv3ntF6dIqlY7wXghk99VW56UUUv+H2mtflKQY+OFedwfMrEa/TIaZNE/T3ZNSC
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA1PR15MB4370.namprd15.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(3613699012)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: ashr2wWA94trsPmtJqrmhOrzDy24yp0och+thtjkv+soFe9PmsSjACTJ+2m3XGKqG6i4kGrxJii6N4PpHMfXBJpmaQ/AKpcGJCzVQxEj9mN1DT0qnjurQedt/Sc9GZFV8yMlpuX0ay34gFeSlaLWP6AX06NpotPIHs4lx4CdufQWo8/YxFJhS3XvkX4E1/KJoWbU3bWpXmset6QIosHMBbYbS7Pdq9ZM5ZNQgVvQH403+5nPBDGYndNQGGTAJk+GajqokBWOky3axve2x5y+WhSx3H+FrUg8CTeGXChkbxM2d0Dwq9aRuWc5S1OiQM/Jqqo6a16tLBLqsWb47WgsF014eqCNiaw5Hiue57zc1jAJLECNvVvN7pT2RV5Ervc7sgfnyw2mXf9m3u1YidJUq+lDRdO0sKU5ewAj4EUHahbrDcxycqhFSeSCH4fvMGKHBz0IUgYz4pZJVcsJ5Sokc8Du2uOdHpfwRGE/zRqIjF8Rf5xJMZg91quRZ+o6rrH65M34EkVZSeXmDxRK6noBkDHMrU7waQZBsQBh3Dh9aB5sJqMsLfAotEtZ0LtgIJCl43TnKdjW0gawWdjoFFJ2A5M1bugR1xw1dETWQQlJPjYPxhvIpPyNEcZ21IERbERNllfM+HT1Tr5vXTGz3CATjr7IBczmuvG5xgBxKvpdgyAoho+9eBT39klkAdS12Jyf09LZWz+qXQnFNtdW5g0znQ4jHJv5eeuK/zmocOTHG70ys7PZSuvkMuiK+FPwryu2fkQxVrt86Bgg6GcaKKZKGUEwffAJE0nULSluwxmmtE6CSEFRTW2PZ6zkfqxq5cL/VcATPZFmN4gVP6XJecO8KPC4GJfox7Ge/WNwYwML2rK7t5hPvHStDsCPfTGQ1imri/s1+M3BBzqITCPJc06iRkTmUtGZd7EMYKENyyFFxG7Ginx4rEroBQx1cZqkwPWYnYXP5pBnmwxccuWj7hEj6na4rM47a5D5urG8XILCoe4NgxBLu41FCeU+QWgxCAbClDvZcKpLHDx9MY2E0L/oeUnOkTzTIweUYrPJrP63Zrgnb2M42rpLCSgbtCoDQvwJsPcuL3To66bfqjErrCJyji46BnQ33Jndlh9AeoM/Uo6JNTSzUoTjdQCYTK8xFepAxqVBuHqSw21Y7ZdH6E7VK+zj0L+57aVbwofZYV0TXTboT5G+/4z90NSO0MHhLge7D3VgLhPwtfhxZdYsz4V6OaguvFuUsT37Lq+su0fHACuPb33BWhKtnOJI/ZVZ9NjL1jhFkZ6inz/TxZ9Or0LO/IJvIecfHfe8sB+z01MLY1snwiACIN62Kb/vQIUQP/4RK0WhqXA+cP9uXipdthU0Ib/uMgnXX+0UUzUeJC/MKYqq0G++AxXvVZdfuyVmANK2iqMTpL7q0tud/4RSNrwX9gz5/+9yG2GXeJxsid0ibntxVeqmmIKqo+q2QhNrKn/dOt5UQPj829cDKpmPmLcpMyoRgMz1n45UvVg0vdCYvBf3tHl0BVQ40yrjz+cP47kqXzf2A8QWwE8qGik6a1aFwoJwOVWWEMeAuRdYyZEtblw=
Content-Type: multipart/alternative; boundary="_000_SA1PR15MB43706FB732C8F277D7FE4E78B3DB2SA1PR15MB4370namp_"
MIME-Version: 1.0
X-OriginatorOrg: meta.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA1PR15MB4370.namprd15.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8d28bd27-2f20-44fc-d10e-08dca04e95ee
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2024 19:37:36.2824 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: LqjcbGJLSuzyjb8VNCUKNoJYIYuwTtJQVerX1pHJhJQR6+3ZimdOGeN3GA9Bf4BQ
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY3PR15MB4947
X-Proofpoint-ORIG-GUID: IN6haoOaiiMgUzeKUboLIVWtdZpej7Yf
X-Proofpoint-GUID: IN6haoOaiiMgUzeKUboLIVWtdZpej7Yf
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16 definitions=2024-07-09_08,2024-07-09_01,2024-05-17_01
X-W3C-Hub-DKIM-Status: validation passed: (address=prvs=29208bb8aa=bemasc@meta.com domain=meta.com), signature is good
X-W3C-Hub-Spam-Status: No, score=-2.3
X-W3C-Hub-Spam-Report: ARC_SIGNED=0.001, ARC_VALID=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, DMARC_PASS=-0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLACK=1.7, URIBL_DBL_BLOCKED_OPENDNS=0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: pan.w3.org 1sRGen-006hJP-2b 2399dcd823d944f0cccabe95bdcaa424
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Proposal: a new WRAP UP capsule
Archived-At: <https://www.w3.org/mid/SA1PR15MB43706FB732C8F277D7FE4E78B3DB2@SA1PR15MB4370.namprd15.prod.outlook.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/52062
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/email/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

I agree, an "I support WRAP UP" signal is not very useful for the server.  It's useful for the server operator, to try to answer questions like:

* Do enough of our clients support WRAP UP that we should invest some effort implementing it?
* Is our implementation of WRAP UP working correctly?
* How long a grace period do we need to offer to reach 99% graceful termination among supporting clients?

--Ben
________________________________
From: David Schinazi <dschinazi.ietf@gmail.com>
Sent: Tuesday, July 9, 2024 1:39 PM
To: Lucas Pardue <lucas@lucaspardue.com>
Cc: Ben Schwartz <bemasc@meta.com>; HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Proposal: a new WRAP UP capsule

Thanks all. Regarding adding a signal to indicate client support, I agree with Lucas: the policy will enforce a hard limit set by policy, no matter what the client does. I don't think the proxy would change its behavior if it knew whether

Thanks all.

Regarding adding a signal to indicate client support, I agree with Lucas: the policy will enforce a hard limit set by policy, no matter what the client does. I don't think the proxy would change its behavior if it knew whether the client supported this.

Regarding capsule vs h2/h3 frame, that's an interesting question. Fundamentally, this signal is intended to flow from proxy to client - even if it has to go through intermediaries between the proxy and client. If we use an h2/h3 frame, we would have to define it such that intermediaries need to understand it and forward it down the chain. We'd also lose h1 support. And intermediaries that use h1 on the back end aren't uncommon these days. Because of these reasons, I think a capsule makes more sense. That said, this does require the capsule protocol to be in play. I think this ties in to the conversation we've been having around connect-tcp and whether to use capsules there.

In terms of my token-limited use case, I think the best design for large uploads/downloads is to use multiple separate proxied requests leveraging range requests or resumable uploads. The alternate REFRESH_TOKEN design would work too, but it has the downside of not working when the proxy is going down for maintenance.

David

On Tue, Jul 9, 2024 at 8:38 AM Lucas Pardue <lucas@lucaspardue.com<mailto:lucas@lucaspardue.com>> wrote:


On Sat, Jul 6, 2024, at 01:03, Ben Schwartz 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?
I think the outcome is the same either way, a proxy can give a hint to a client using the capsule and it might not be able to do anything with it anyway even if understood. The proxy still needs to enforce its policy on when to shut the thing down.



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.

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.

[1] https://httpwg.org/http-extensions/draft-ietf-httpbis-resumable-upload.html#section-8.2<https://urldefense.com/v3/__https://httpwg.org/http-extensions/draft-ietf-httpbis-resumable-upload.html*section-8.2__;Iw!!Bt8RZUm9aw!5D2F-R2U09uUsHaJTNnEX9Xq4f_TvBt5L2Hmm7KlH2kvxPvjgnHkmRihnSxEq7Uouma5RPOk3H-vkQizjtgb$>

--Ben

________________________________

From: David Schinazi <dschinazi.ietf@gmail.com<mailto:dschinazi.ietf@gmail.com>>
Sent: Friday, July 5, 2024 6:29 PM
To: HTTP Working Group <ietf-http-wg@w3.org<mailto: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

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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-schinazi-httpbis-wrap-up/__;!!Bt8RZUm9aw!5D2F-R2U09uUsHaJTNnEX9Xq4f_TvBt5L2Hmm7KlH2kvxPvjgnHkmRihnSxEq7Uouma5RPOk3H-vkV2Dmq1-$>
https://davidschinazi.github.io/draft-schinazi-httpbis-wrap-up/draft-schinazi-httpbis-wrap-up.html<https://urldefense.com/v3/__https://davidschinazi.github.io/draft-schinazi-httpbis-wrap-up/draft-schinazi-httpbis-wrap-up.html__;!!Bt8RZUm9aw!5D2F-R2U09uUsHaJTNnEX9Xq4f_TvBt5L2Hmm7KlH2kvxPvjgnHkmRihnSxEq7Uouma5RPOk3H-vkZyAeSrI$>

I'd love to hear your thoughts.

Thanks,
David

Proposal: a new WRAP UP capsule David Schinazi
Re: Proposal: a new WRAP UP capsule Martin Thomson
Re: Proposal: a new WRAP UP capsule Ben Schwartz
Re: Proposal: a new WRAP UP capsule Valentin Gosu
Re: Proposal: a new WRAP UP capsule Lucas Pardue
Re: Proposal: a new WRAP UP capsule David Schinazi
Re: Proposal: a new WRAP UP capsule Dustin Mitchell
Re: Proposal: a new WRAP UP capsule Ben Schwartz
Re: Proposal: a new WRAP UP capsule Lucas Pardue
Re: Proposal: a new WRAP UP capsule David Schinazi
Re: Proposal: a new WRAP UP capsule Tommy Pauly
Re: Proposal: a new WRAP UP capsule David Schinazi