Received: by ietfa.amsl.com (Postfix) id 5BE13C1840D2; Tue, 9 Jul 2024 03:03:50 -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 5AF1FC180B7D for ; Tue, 9 Jul 2024 03:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.855 X-Spam-Level: X-Spam-Status: No, score=-2.855 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, 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="CYuhxlGN"; dkim=pass (2048-bit key) header.d=w3.org header.b="XPuXSmbZ"; dkim=pass (2048-bit key) header.d=gmail.com header.b="fuGg3bXc" 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 Gj9ktrjyF83W for ; Tue, 9 Jul 2024 03:03:46 -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 A4113C151552 for ; Tue, 9 Jul 2024 03:03:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Subject:Content-Type:Cc:To:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To; bh=Dfv7gGtl2BBhhXYfKoWXWjbUSvYRrKiCxUpqyL56bck=; b=CYuhxlGN9RI51sz6ukWkWXhIy1 dMKhvDkzrh7TvGs4ovEjhADF5MoY/CEka1J5Qiolb5zwmcAHqzs29nlMrZVwE1PLniVCVedKVD7Q4 pKOVPdvBMAfQ3ReTREqrk3Etsta2zpJZzWV6AcHIRFqolFqWSEbOXCPFMUoV5OaFhwwgXghX2PYCl eMW61ZtJ/Zd10NJtkGibwmiHduFiqSIKLiWMmmRx3GigCj2tDN7XExJzHOX1hCWrJo7N6NkjG0l30 X2iDfUvJOVfNN8RZmMfm02v9vVPARNu5BjrngIH0QE41WxJ5Ih11reGUYOwDhuNEj/hg2eNOmo+hK m7c1GW5w==; Received: from lists by mab.w3.org with local (Exim 4.96) (envelope-from ) id 1sR7gO-00CfeU-1w for ietf-http-wg-dist@listhub.w3.org; Tue, 09 Jul 2024 10:02:48 +0000 Resent-Date: Tue, 09 Jul 2024 10:02:48 +0000 Resent-Message-Id: Received: from ip-10-0-0-224.ec2.internal ([10.0.0.224] helo=puck.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 1sR7gL-00CfdY-0t for ietf-http-wg@listhub.w3.internal; Tue, 09 Jul 2024 10:02:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To; bh=Dfv7gGtl2BBhhXYfKoWXWjbUSvYRrKiCxUpqyL56bck=; t=1720519365; x=1721383365; b=XPuXSmbZOCORoP8eGQcqHltEmgDR38UKRkjh7MaqcQT1Bhs6IFpMZTLLfKrvVAVVrG9AhgyBGNa OohcYfW8Sf7wtGgtQc19XIqpG9vgpE8NqbK8xsBiEc1MhwVaK2xvNZaCbeY957YYhl7ZxAqMYOmU/ DMLWS4GjbUeQ4ClHC6Pi6QmptWzkh900VSdHqMyyoejjcx+xY2Y62YAa7gM8/ma8j7r3DStTUg9cz Po+kFq50/Tru/kCRzUBxWS28RF8iQcaxoiu+JmRvRM2G0ZhGJ2qH6MC6szMPLvahQBQYyPTssIGnJ sUu6NoP/Bz95J8GivgJw1JrSr816YEug1G3A==; Received-SPF: pass (puck.w3.org: domain of gmail.com designates 2001:4860:4864:20::33 as permitted sender) client-ip=2001:4860:4864:20::33; envelope-from=valentin.gosu@gmail.com; helo=mail-oa1-x33.google.com; Received: from mail-oa1-x33.google.com ([2001:4860:4864:20::33]) by puck.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1sR7gK-00GJzv-1j for ietf-http-wg@w3.org; Tue, 09 Jul 2024 10:02:45 +0000 Received: by mail-oa1-x33.google.com with SMTP id 586e51a60fabf-25e3d8d9f70so2366126fac.2 for ; Tue, 09 Jul 2024 03:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720519361; x=1721124161; darn=w3.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Dfv7gGtl2BBhhXYfKoWXWjbUSvYRrKiCxUpqyL56bck=; b=fuGg3bXcFhts3oV6Et9q77iR2by6N/GCtm+CKfCaqTr1WDn8+1BkP9Cqk58EsZsf5l 9UMzYv4LtLsDmI+YX8jKacViItpfYzizVvBRpJAsryVkml8A66XZiBbxZBF9hltbx4Od SlKFbe3AzpwqFeEb07bYnnyKupBzi7Nh6gXb2giERKmMk8UgYlRe0HaLXE5Ntp6+/lJW pfpjvH8C3xr1J50vCSNrnrDkggok9x57ZjOetFglAbMs/pdvfjdDA6UbKmj5UaFP/JVC SSKdYWWXBTaWhyoAQClUAQ2XXAKIaa+0duzoeY7ZKOjaEY8gvoqMocY4GA8jeG0W00rH Ui6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720519361; x=1721124161; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Dfv7gGtl2BBhhXYfKoWXWjbUSvYRrKiCxUpqyL56bck=; b=O3Vu/qhdnVtIQ73YkTY3AaGY8xfDt1z1ttQMSbjv+KQ9NJV6O3qXuCYuWrLx1pTZwb bdY5cyuOh/cWuPPDST1Mxfe+X2g5ocx8KwYJosMEyDa1xqRTAcN2kwE1NXUtBDPx8dQM ET32KPDvLwrIIAewXaBBNx+ACKDz7EE5fGJ67M1R79XUCuausaEWuOvLU6L+ivJzPyu/ ZflNLOZF9X0u+0FQTwvBeGnpDr0wsbTYUZavfIdDof0UGJPrljDcRgLVuYORbV9dqApO znGmcNydMjZRU+ULt7jcvWHdegde51ExJn4tQNL3UquFeNQzb5yYu37K8PQX9MC7rnXM 0m1Q== X-Forwarded-Encrypted: i=1; AJvYcCV2Mam3lg8aG+3/voe5onW3aOKIG/L1GT+cWEI8CJcHp5UDwCtDIBrSiHBT08rS1k8Qhr5ug+7d0H1A0QBOVHJwpieP X-Gm-Message-State: AOJu0YwRfS8m9NnmDT/0+hgAHgs3Jc8uqUw/1rxq9tKrk/+YXvnKMYjL 5jhLx+imOJHjniT8IhI7omhzQCbrUYQpCq+0TU9+uIIVD91eLtvsMbjO0UzmVMMCMjfc9U8/3SW uQ8UvHY8DntyULQ6N45U7itaKKsGoo0pVOqM= X-Google-Smtp-Source: AGHT+IERf9qLOuLKXzm6euYl97dg6NVAfgyLbzjEFL1HvH87UuD/bcCKjgpLTMMUkVeKIWJ+6cwH6+RyFxY5JExe5J8= X-Received: by 2002:a05:6870:8193:b0:254:b420:5ab with SMTP id 586e51a60fabf-25eae78463bmr1610707fac.8.1720519360597; Tue, 09 Jul 2024 03:02:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Valentin Gosu Date: Tue, 9 Jul 2024 12:02:28 +0200 Message-ID: To: Ben Schwartz Cc: David Schinazi , HTTP Working Group Content-Type: multipart/alternative; boundary="000000000000515782061ccda17f" X-W3C-Hub-DKIM-Status: validation passed: (address=valentin.gosu@gmail.com domain=gmail.com), signature is good X-W3C-Hub-Spam-Status: No, score=-3.4 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_PASS=-0.001, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=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_DB=-1, W3C_WL=-1 X-W3C-Scan-Sig: puck.w3.org 1sR7gK-00GJzv-1j 30ef8c53bff61b74bbe967b07a6d4f8a 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/52057 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: --000000000000515782061ccda17f Content-Type: text/plain; charset="UTF-8" Hi David, I really like your proposal. As Ben noted, this sort of control plane signaling would be useful for other kinds of HTTP tunnels. I'm also interested in your use case - what happens if a user wants to upload/download a very large resource through the tunnel without being aborted? Would a pay-as-you-go model be viable, where in response to a WRAP_UP capsule the client responds with a REFRESH_TOKEN that extends the lifetime of the tunnel? --Valentin On Sat, 6 Jul 2024 at 02:07, 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? > > 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? > > --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 > --000000000000515782061ccda17f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi David,

I really like your= proposal. As Ben noted, this sort of control plane signaling would be usef= ul for other kinds of HTTP tunnels.

I'm also i= nterested in your use case - what happens if a user wants to upload/downloa= d a very large resource through the tunnel without being aborted?
Would a pay-as-you-go model be viable, where in response to a WRAP_UP caps= ule the client responds with a REFRESH_TOKEN that extends the lifetime of t= he tunnel?

--Valentin

On Sat, 6 Jul 2024 = at 02:07, Ben Schwartz <bemasc@meta.c= om> wrote:
I think this is a reasonable idea.=C2=A0 Two questions come to mind:

1. Should this have a signal?=C2=A0 Right now there's no indication fro= m the client about whether it supports this frame.=C2=A0 That makes it diff= icult for the server to understand whether the frame is working as intended= .=C2=A0 Did I not give a long enough grace period, or are these clients running long because they don't recognize the cap= sule?

2. Should this be a stream-scoped HTTP/2+3 frame type?=C2=A0 There are lots= of cases of streaming requests and responses that might encounter some kin= d of limit in HTTP, including WebSocket, WebTransport, and even plain old P= OST and GET.=C2=A0 Should "this stream is getting too long for me" be a built-in function of HTTP?

--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
=C2=A0
Hi HTTP enthusiasts, Over in MASQUE land, as we're deploying our two-ho= p proxies, we decided we needed to put a cap on how many bytes we'd all= ow per token-authenticated connect-udp tunnel. Enforcing a hard limit is ea= sy, but the issue
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
=C2=A0
ZjQcmQRYFpfptBannerEnd
Hi HTTP enthusiasts,

Over in MASQUE land, as we're deploying our two-hop proxies, we de= cided we needed to put a cap on how many bytes we'd allow per token-aut= henticated connect-udp tunnel. Enforcing a hard limit is easy, but the issu= e is that if the proxy aborts the tunnel halfway through, the web browser could be halfway through a proxied reques= t. Since the browser doesn't know if the half-finished request was acte= d on or not, it can't retry it, so it has to surface the error to the u= ser. Instead, we want the proxy to be able to warn the browser that this will happen soon, so that the browser can es= tablish a new tunnel with a new token, and start sending new requests there= . Conceptually this is a little like GOAWAY, but instead of "please wr= ap up this connection", it's "please wrap up this tunnel stream". It uses capsules, since this is a messag= e from proxy to client. Here's a draft with diagrams:


I'd love to hear your thoughts.

Thanks,
David
--000000000000515782061ccda17f--