Received: by ietfa.amsl.com (Postfix) id CE7BBC15107F; Tue, 9 Jul 2024 08:39:59 -0700 (PDT) Delivered-To: ietfarch-httpbisa-archive-bis2juki@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8A4C15106A for ; Tue, 9 Jul 2024 08:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.745 X-Spam-Level: X-Spam-Status: No, score=-7.745 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, TRACKER_ID=0.1, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=w3.org header.b="PE93hDiv"; dkim=pass (2048-bit key) header.d=w3.org header.b="IwUqN72A"; dkim=pass (2048-bit key) header.d=lucaspardue.com header.b="lWRNqKml"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="ECOwbZBj" Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71Jje0zJv7H5 for ; Tue, 9 Jul 2024 08:39:55 -0700 (PDT) Received: from mab.w3.org (mab.w3.org [IPv6:2600:1f18:7d7a:2700:d091:4b25:8566:8113]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44645C14F697 for ; Tue, 9 Jul 2024 08:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Subject:Content-Type:To:From:Date:References:In-Reply-To:Message-Id: MIME-Version:Cc:Reply-To; bh=WH2HQoSp2MsiKVKQ24fxsBpVjx0UnVI+OecXpMrx278=; b= PE93hDiv/Jdoxp/lFz5ykOXCMuCk7ckXrC84WWAA4gwsqwZv96qvcjfcpR+DfSd7GkUiMhP/SQKYk 8W2tqGGBBdP+Ib8udNNTHDV1mPujBCsuE+61fzF487D57amv/9gH6PxzWgji/sY5FBU6cG7KZZ4Bf mYd+d2MOH1/5rydEWtwC8a8cwlxMMzrWZAf3rJLANiVkTtDMCuSIB/JpbGWqeFJgVnMdJLLAq+BJ3 jT8UMndiOGZKNSlCAvo51V87UVD8e8yHMCcILHhuZYlweBXpTx6JT1sN4KBjbBt4l9u1QzkUPw3Nq L968e6gYxf02nmFhNOr76bcSLjVeHd+Kxw==; Received: from lists by mab.w3.org with local (Exim 4.96) (envelope-from ) id 1sRCvP-00DUkz-0f for ietf-http-wg-dist@listhub.w3.org; Tue, 09 Jul 2024 15:38:39 +0000 Resent-Date: Tue, 09 Jul 2024 15:38:39 +0000 Resent-Message-Id: Received: from ip-10-0-0-144.ec2.internal ([10.0.0.144] helo=pan.w3.org) by mab.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1sRCvN-00DUk3-0Q for ietf-http-wg@listhub.w3.internal; Tue, 09 Jul 2024 15:38:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Content-Type:Subject:To:From:Date:References:In-Reply-To:Message-Id: MIME-Version:Cc:Reply-To; bh=WH2HQoSp2MsiKVKQ24fxsBpVjx0UnVI+OecXpMrx278=; t=1720539517; x=1721403517; b=IwUqN72AtCbXP8iUACbFB/F4FR1NtFnDluymcES5i9RYyjv PXFDfKshBUcv2IUlTI3s6eiNxihGueQjzsq04XgCq6rte6kbFRde9Jf4VhfGyUj96DOHOcc2QGacT GX8IwCCVq4WJy7M0wbZyFs2JgXb5RxMCqvb9jgwscpqieLZF1b7cp8KosZOZ8S8Rv1wDShaZpNBlJ X5czeTcbBeyr/2EpPXl0060BgjpaTXXEBVjnehwWsRLfzW9+O6e2PUyRCgYvnjR3W7+RbVvpZB3w2 nUuN0cHzRaxK3uUuI33Vy2l3ZoM2quDQFQAQvoCGvBHvrvwN4ScbEsIQlVW1Ye5g==; Received-SPF: pass (pan.w3.org: domain of lucaspardue.com designates 103.168.172.145 as permitted sender) client-ip=103.168.172.145; envelope-from=lucas@lucaspardue.com; helo=fout2-smtp.messagingengine.com; Received: from fout2-smtp.messagingengine.com ([103.168.172.145]) by pan.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1sRCvM-006dAZ-0n for ietf-http-wg@w3.org; Tue, 09 Jul 2024 15:38:37 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailfout.nyi.internal (Postfix) with ESMTP id 0A4BF1380848; Tue, 9 Jul 2024 11:38:33 -0400 (EDT) Received: from imap53 ([10.202.2.103]) by compute3.internal (MEProxy); Tue, 09 Jul 2024 11:38:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucaspardue.com; h=cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1720539513; x=1720625913; bh=WH2HQoSp2M siKVKQ24fxsBpVjx0UnVI+OecXpMrx278=; b=lWRNqKml4dVI/F1Io+XObxPs7/ VriQjnvFkRlXPBvxU0LuBE0q1Hb/aJMRS7D+rLHM5weyHBaZG/wcVEkAtXBzkD+y N/T66vItqp93bl9WYMCT/lWBqQeCE7p6kzVdfH3yGmELEngMuCQMGu0d3mZL9xGJ yl0kSy7dYSLy2KTONd/4PiDYP3f5UxOTqAsAJW12Acqhw00h98QSVaoKgaVVFy3H TzqVCcYfX1ZO9vlFylj9BQpOuEA9RdCzcxxHy+XW4NepbZMHacFPCR5HbsfHUiit vG8UrJQ6PWR9FOVv3smKbQdr33oVwblbygzvsxWBf0Ilm8hD3GvE05VFk46g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1720539513; x=1720625913; bh=WH2HQoSp2MsiKVKQ24fxsBpVjx0U nVI+OecXpMrx278=; b=ECOwbZBjJl3TSFm92pRj6FEfvJP9zI2rodB6sMSblBuG HrLAaBi+fSPSpct4drVkJTPKZmcz2p6BbxVmGsmIYzP9JMSasLNPf4NT+EMbMrM3 Uo3oRFNsaSzSJKP8O7jDtLw1p+rXzqkav3VUDQNqGJ43yMmr3fzSq8E7PL0gUJsy DepObVfBkH4ukTp6G0Owa/IF190HOt7jsY2Dv/1oanX74fnwdYzNt5mdcIrUXapS ea9lPnZO3hjL5Gxitu1EadSCXNaBe653nLJSUuIPRX6h9rxjJ6KZg01QxCf+OB/x iNmS/PXe0DqLKGOd+aGG1rtbFbl2dtfN3e6WQcy9DQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdelgdelvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecuogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenhd fknhhvihhsihgslhgvucifohhrughsucdlhedtmdenucfjughrpefofgggkfgjfhffhffv ufgtsegrtderreerredtnecuhfhrohhmpedfnfhutggrshcurfgrrhguuhgvfdcuoehluh gtrghssehluhgtrghsphgrrhguuhgvrdgtohhmqeenucggtffrrghtthgvrhhnpefggeeu vdeukeegvdegffdvjeeitdeugffgheffffduffdvhfdvfefhgfevieeffeenucffohhmrg hinhephhhtthhpfihgrdhorhhgpdiffedrohhrghdpihgvthhfrdhorhhgpdhgihhthhhu sgdrihhonecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh eplhhutggrsheslhhutggrshhprghrughuvgdrtghomh X-ME-Proxy: Feedback-ID: i23b94938:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 70A263640072; Tue, 9 Jul 2024 11:38:32 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-568-g843fbadbe-fm-20240701.003-g843fbadb MIME-Version: 1.0 Message-Id: <8ada24df-9941-4a37-b79b-8ef471c5459d@app.fastmail.com> In-Reply-To: References: Date: Tue, 09 Jul 2024 16:38:07 +0100 From: "Lucas Pardue" To: "Ben Schwartz" , "David Schinazi" , "HTTP Working Group" Content-Type: multipart/alternative; boundary=d546def8646e417bb067fc347253c228 X-W3C-Hub-DKIM-Status: validation passed: (address=lucas@lucaspardue.com domain=lucaspardue.com), signature is good X-W3C-Hub-DKIM-Status: validation passed: (address=lucas@lucaspardue.com domain=messagingengine.com), signature is good X-W3C-Hub-Spam-Status: No, score=-2.3 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, DMARC_MISSING=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TRACKER_ID=0.1, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLACK=1.7, URIBL_DBL_BLOCKED_OPENDNS=0.001, W3C_AA=-1, W3C_WL=-1 X-W3C-Scan-Sig: pan.w3.org 1sRCvM-006dAZ-0n ad37d6f5d79f1d5f9a1d615ec379ae05 X-Original-To: ietf-http-wg@w3.org Subject: Re: Proposal: a new WRAP UP capsule Archived-At: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/52058 X-Loop: ietf-http-wg@w3.org Resent-Sender: ietf-http-wg-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: --d546def8646e417bb067fc347253c228 Content-Type: text/plain 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 > --Ben > > > *From:* David Schinazi > *Sent:* Friday, July 5, 2024 6:29 PM > *To:* HTTP Working Group > *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 --d546def8646e417bb067fc347253c228 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

=

On Sat, Jul 6, 2024, at 01:03, Ben Schwartz wrote:
I think this is a reasonable idea.  Two questions come to mind:<= br>

1. Should thi= s have a signal?  Right now there's no indication from the client a= bout whether it supports this frame.  That makes it difficult for t= he 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 caps= ule?
I think the outcome is the same either w= ay, a proxy can give a hint to a client using the capsule and it might n= ot be able to do anything with it anyway even if understood. The proxy s= till 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 limi= t in HTTP, including WebSocket, WebTransport, and even plain old POST an= d 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 nessag= e travel and what the limit applies to.

On= e 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 request= s and aggregate size

What single transactio= n 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 rese= t the stream. 

WebSocket is a bidi pip= e and similar to MASQUE flows., I could see wrap up applying there. The = capsule seems like it would work too.


=
--Ben=


From: David Sch= inazi <dschinazi.ietf@gmail.com>
Sent: Friday, July 5, = 2024 6:29 PM
To: HTTP Working Group <ietf-http-wg@w3.org&g= t;
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 al= low per token-authenticated connect-udp tunnel. Enforcing a hard limit i= s easy, but the issue
= ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

 
<= /div>
ZjQcmQRYFpfptBannerE= nd
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 toke= n-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 req= uest. Since the browser doesn't know if the half-finished request was ac= ted 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 "pleas= e 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:

--d546def8646e417bb067fc347253c228--