Received: by ietfa.amsl.com (Postfix) id C0721C1840C7; Thu, 25 Jul 2024 15:28:49 -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 BFAE8C16940B for ; Thu, 25 Jul 2024 15:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.857 X-Spam-Level: X-Spam-Status: No, score=-2.857 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_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_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="hzvNTjE0"; dkim=pass (2048-bit key) header.d=w3.org header.b="d38gHaml"; dkim=pass (2048-bit key) header.d=gmail.com header.b="fBtvCD/e" 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 Wc-b-A0W1SjH for ; Thu, 25 Jul 2024 15:28:45 -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 B3173C14F6A5 for ; Thu, 25 Jul 2024 15:28:45 -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:Message-ID:Date:From:MIME-Version:Cc:Reply-To :In-Reply-To:References; bh=VzQftKnXnNpcsyhgz4Q+Ec3Sux4ZYbDZmVjgaIvKn7k=; b=h zvNTjE0J2rDEImKwJt0zLu7NEGbkycQ8GbZlu0ZnbteQGXAlqN86YSomYsWGpGztENRoBM+8ukqku aN52SoNbdZBM62fpIZxi7TsETZiqGb+gKilTqQo4arJwF39cjhHWEx8XPLuYWmaIQOax1MkVetTGO 0uJwpdRroDKe0A8GGzMWTqyMKZMRg3x5yQ8WaDAIDP43If5GR5yEIPM0qma13W2htHG2xCCxbmsfZ NAw4QhHds2D0AkxHAZ2GGgnLzrISrlfXkGFdUlrD9uL9A6mBILpK+GDjAQveiFWP5XEsRBBtCx7Ke 2ZZ66oSxYSAsUEgHvuiLcAVr+b5wQf9YQ==; Received: from lists by mab.w3.org with local (Exim 4.96) (envelope-from ) id 1sX6wD-0083no-1P for ietf-http-wg-dist@listhub.w3.org; Thu, 25 Jul 2024 22:27:53 +0000 Resent-Date: Thu, 25 Jul 2024 22:27:53 +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 1sX6wB-0083mt-1X for ietf-http-wg@listhub.w3.internal; Thu, 25 Jul 2024 22:27:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Content-Type:To:Subject:Message-ID:Date:From:MIME-Version:Cc:Reply-To :In-Reply-To:References; bh=VzQftKnXnNpcsyhgz4Q+Ec3Sux4ZYbDZmVjgaIvKn7k=; t=1721946471; x=1722810471; b=d38gHamlYxWduAIS2x5tlLNbR4lbNgAz3bTst+QAuM8YbWk LfIAdfuieJlG4eKqbLNCHsIMeXVtiKqzN7FfmuisIyksPhz4IOnJHo4K7dF3g2uZPKlZjSuKvz721 govfEVk+/bROvvdYoc7146uVnjc014//YjEqovBwaoIXjKwgBnaHexjLgfUOBeQD3KFVtDWDHWo0w RbgW5HfcKeLZaMs3Hw1uIS5UhiEWCQaG8ey1Lch+45x3aufPRMZVTUDtR8Kfo2d8eN1b1p/0K1nRd VESJPili0FRHOS1fTAZaPhfTSjm/LU7rUlpmlmLOZbK2ZgAQWcWbcziF7z9hhirA==; Received-SPF: pass (puck.w3.org: domain of gmail.com designates 2607:f8b0:4864:20::332 as permitted sender) client-ip=2607:f8b0:4864:20::332; envelope-from=joshco@gmail.com; helo=mail-ot1-x332.google.com; Received: from mail-ot1-x332.google.com ([2607:f8b0:4864:20::332]) by puck.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1sX6wA-004aG6-2Q for ietf-http-wg@w3.org; Thu, 25 Jul 2024 22:27:51 +0000 Received: by mail-ot1-x332.google.com with SMTP id 46e09a7af769-7092ea69218so164053a34.1 for ; Thu, 25 Jul 2024 15:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721946467; x=1722551267; darn=w3.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=VzQftKnXnNpcsyhgz4Q+Ec3Sux4ZYbDZmVjgaIvKn7k=; b=fBtvCD/ewt3zTAq6FKy98oIJFE31KKshbhTHfd7eIk37AGJgO+KeyreuBDWjB6XWA1 RfQ982P3BU2ZCZGYOONe5aJ83OtRM+Vf7gW3xH6+vOyvW8yF1mS5DpjjU+rUEt1WjuWB d0gFF+g+PTHirwSNf1odK1HrAT/MZ9Ox7trCJ77oQpP89uKBjYtcBaWcE4HSvSZOMQKj JbVMZc0w4jNPWmYo2QjQ6Kj7pgRb+qiM6wRrsriaYKIoVWPSFTFcfBctTf8U60JrpLrP F+zjhzdMxIxfJfnLPiittmsG14jjlMu/AkHDBBxiipyQClegQwkVxU0p29DSdmc3bzve 66hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721946467; x=1722551267; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=VzQftKnXnNpcsyhgz4Q+Ec3Sux4ZYbDZmVjgaIvKn7k=; b=jqB1QAPow8iwTodG/iUvhk/VrpaRmz6kNHCSGrHjX4fEoNjzA5Ai8DlgXytJTAnmzF zgPVnvpnA3KIIJ/qTg8iknjBN7tNhl5EA+yZ7Iq9gzvzgtA3ZiFvNuO5A16LJ5M45vyx spCpMBbTCWLwZJzoX8pIg3Erw1vkZMrsao9X+8yux/pr2lim1luGx5zpufV5xdahh7lW BebVn8CoRaid5k4YlYSzrMF5zHdiTUkOEYcCkWFDT4maNn2G62Ig+uu+953S002rqE1g yAHo4Q8fWyi1N70q4b3cPvEFDhllBGC/m7UpnxwuJ0/3rnv7CQoIJ2y6GQxAFD1Mxe0k j8zg== X-Gm-Message-State: AOJu0YyjEpgT+HHqlxHZtNzcGDfJLzFQl6CyS/Z9RldMj5DD2Q6A8mwS /iFAKSCqANCQ0qC5Be9FSxAf295WdbaR54puRQMBXTFE8wgIR4U5RKXkl8/WTC8MvBMfKUlTrY5 pZS85Q2FfY9eVhvqKNBKCCs0W5MmRfdY+jAe2aA== X-Google-Smtp-Source: AGHT+IEKyskMGOQgGDgcpm4F4mRBD1bn/HbuXVZomi+UGmHRvP8AqAiMD1IXcdSJBApheot7cpBAbfgpwJXw0e6Gq3s= X-Received: by 2002:a05:6808:f0f:b0:3d9:3427:56b9 with SMTP id 5614622812f47-3db10a01047mr2213619b6e.4.1721946466630; Thu, 25 Jul 2024 15:27:46 -0700 (PDT) MIME-Version: 1.0 From: Josh Cohen Date: Thu, 25 Jul 2024 15:27:36 -0700 Message-ID: To: HTTP Working Group Content-Type: multipart/alternative; boundary="000000000000774592061e19e77f" X-W3C-Hub-DKIM-Status: validation passed: (address=joshco@gmail.com domain=gmail.com), signature is good X-W3C-Hub-Spam-Status: No, score=-6.1 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_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1 X-W3C-Scan-Sig: puck.w3.org 1sX6wA-004aG6-2Q b57b01f7bf188ee85318d833835c969e X-Original-To: ietf-http-wg@w3.org Subject: Method Mania Archived-At: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/52141 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: --000000000000774592061e19e77f Content-Type: text/plain; charset="UTF-8" On the httpwg agenda at IETF 120 were a proposal for a new QUERY method and Braid, which has subscription functionality that overloads the GET method. What I am curious about is if, at this point in the evolution of the web, it is now safe to add new methods for new functionality. I've been reading up on HTTP/2/3 and it seems that nowadays, connections are end-to-end secure and are essentially tunneled through middle boxes, including HTTP/1.1 proxies. I'm still just wrapping my head around MASQUE, but it looks like it can handle arbitrary methods. Similarly origin servers have evolved to support arbitrary methods. The assumption I am making is that this is true. I am curious what others think, and what the common mindset is. Eg do people shy away from new methods, or not? Braid In the Braid internet draft[3], section 2.5 states: If the request contains a Subscribe header, then it SHOULD additionally > leave the request open and subscribe the client to future updates. > Otherwise, it should close the connection after sending the updates. That imposes semantics at the connection level which are different from the norm. In HTTP/1.1, the Connection header specifies whether to keep the connection open. In HTTP/2/3, the Connection header is prohibited. Section 4.1 says: A client requests a subscription by issuing a GET request with a Subscribe > header: Subscribe: may be blank, set to "true", or contain arbitrary data, and is > reserved for future use. > This header modifies the normal GET method's semantics, to request a subscription > to future updates to the data, rather than only returning the current > version of the representation data. Another issue is idempotency. From reading the draft, GET with Subscribe header with no value, or true, returns the current version. Since versions change over time, and Braid has chosen to use the same URI for different versions of a resource, resending the same GET with Subscribe will not produce the same result. This violates the idempotency rule. How caches will handle this may be an enigma. An example of SUBSCRIBE, POLL, NOTIFY etc. methods, which were proposed in 1998 is GENA[1]. For historical reasons described at the end of this email, these methods were incorporated into UPNP rather than HTTP. QUERY Method The Internet Draft for QUERY makes a similar argument for why it uses a new method. Section 1.9 [2] describes a current practice of using POST for queries: > This variation, however, suffers from the same basic limitation as GET in > that it is not readily apparent -- absent specific knowledge of the > resource and server to which the request is being sent -- that a safe, > idempotent query is being performed. The QUERY method proposal acknowledges the idempotency issue and addresses it with a new method. *Question* Should Braid follow the QUERY method proposal's example and define new methods for subscriptions? Thes may be useful in cases beyond Braid. History Back in the 1990s, WebDAV was the first post HTTP/1.1 example, that I was aware of, to add new methods to enable new functionality. WebDAV is distributed authoring adding methods like COPY, LOCK, PROPFIND etc. After that, a number of application protocol efforts looked to HTTP as a possible substrate. One draw was its ability to traverse firewalls via proxy servers. Examples were SIP, UPNP and IPP (Internet Printing Protocol). I authored the Internet Draft General Event Notification Architecture[1] which proposed the addition of subscription methods SUBSCRIBE, NOTIFY etc. There was debate about overloading the POST method vs new methods. At the time, many firewalls, proxies, and even some origin servers like Apache didn't support arbitrary methods. The IESG view was that new protocols should use different TCP ports rather than riding on HTTP. The result is that SIP, UPNP, IPP are "HTTP-like" but incompatible protocols. GENA was rolled into UPNP as chapter 4. [1] https://datatracker.ietf.org/doc/html/draft-cohen-gena-p-base-01 [2] https://www.ietf.org/archive/id/draft-ietf-httpbis-safe-method-w-body-03.html#section-1-9 [3] https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http -- --- *Josh Co*hen --000000000000774592061e19e77f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On the httpwg agenda at IETF 120 were a proposal for a new QUERY method and Braid, which has subscription functionality that overloads the GET method.

=C2=A0

What I am curiou= s about is if, at this point in the evolution of the web, it is now safe to a= dd new methods for new functionality.=C2=A0=C2=A0I've been reading up on HTTP/2/3 and it seems that nowadays, connecti= ons are end-to-end secure and are essentially tunneled through middle boxes= , including HTTP/1.1 proxies. I'm still just wrapping my head around MA= SQUE, but it looks like it can handle arbitrary methods.=C2=A0 Similarly or= igin servers have evolved to support arbitrary methods.


The assumption I= am making is that this is true.=C2=A0 I am curious what others think, and what the common mindset is.=C2=A0 Eg do peop= le shy away from new methods, or not?

=C2=A0

Braid

=C2=A0

In the Braid internet draft[3], section 2.5 states:


If the req= uest contains a Subscribe header, then it SHOULD additionally leave the req= uest open and subscribe the client to =C2=A0future updates.=C2=A0 Otherwise= , it should close the connection =C2=A0after sending the updates.

=C2=A0

That imposes semantics at the connection level which are different from the norm.=C2=A0 In HTTP/1.1, the Connection header specifies whether to keep the connection op= en. In HTTP/2/3, the Connection header is prohibited.


Section 4.1 says:

<= p style=3D"margin:0in;font-family:Calibri;font-size:12pt;color:rgb(33,37,41= )">

A client requests a subscription by issuing = a GET request with a=C2=A0 Subscribe header:

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Subscribe: <Parameters>
=C2=A0
<= Parameters> may be blank, set to "true", or contain arbitrary = data,=C2=A0and is reserved for future= use.
=
This header modifies the normal GET me= thod's semantics, to request a=C2=A0subscript= ion to future updates to the data, rather than only=C2=A0returning the current version of the representation data.

=C2=A0

Another issue is idempotency.=C2=A0 From reading the= draft, GET with Subscribe header with no value, or true, returns the current version. Since versions change over time, and Braid has chosen to use the same URI for different versions of a resource, resending the same GET with Subscribe will not prod= uce the same result.=C2=A0 This violates the idempotency rule.=C2=A0 How caches will handle this may be an enigma.

=C2=A0

An example of=C2=A0 SUBSCRIBE, POLL, NOTIFY etc. methods, which were proposed in 1998 is GENA[1].=C2=A0 For historical reasons described at the end of this email, these methods were incorporated into UP= NP rather than HTTP.

=C2=A0

QUERY Method

=C2=A0

The Internet Draft for QUERY makes a similar argumen= t for why it uses a new method.=C2=A0 Section 1.9 [2] describes a current practice of using POST for queries:

=C2=A0

This variation, however, suffers from the same basic limitation as GET in that it is not readil= y apparent -- absent specific knowledge of the resource and server to wh= ich the request is being sent -- that a safe, idempotent query is being performed.

=C2=A0

The QUERY method propo= sal acknowledges the idempotency issue and addresses it with a new method.<= /p>


Question

Should Braid follow t= he QUERY method proposal's example and define new methods for subscript= ions?=C2=A0 Thes may be useful in cases beyond Braid.


History

=C2=A0

Back in the 1990= s, WebDAV was the first post HTTP/1.1 example, that I was aware of, to add new methods to enable new functionality.=C2=A0 WebDAV is distributed authoring adding methods like COPY, LOCK, PROPFIND etc.

After that, a nu= mber of application protocol efforts looked to HTTP as a possible substrate.=C2= =A0 One draw was its ability to traverse firewalls via proxy servers.=C2=A0 Examples were SIP, UPNP and IPP (Internet Printing Protocol).

I authored the Internet Draft General Event Notification Architecture[1] which proposed th= e addition of subscription methods SUBSCRIBE, NOTIFY etc.

=C2=A0

There was debate about overloading the POST method vs new methods.=C2=A0 At the time, many f= irewalls, proxies, and even some origin servers like Apache didn't support arbitrary methods.= =C2=A0 The IESG view was that new protocols should use different TCP ports rather than riding on HTTP.=C2=A0 The result is tha= t SIP, UPNP, IPP are "HTTP-like" but incompatible protocols.=C2=A0=C2=A0 GENA was roll= ed into UPNP as chapter 4.

=C2=A0

=C2=A0

=C2=A0

[1] https://datatracker.ietf.org/doc/html/d= raft-cohen-gena-p-base-01

[2] https://www.ietf.org/archive/id/draft-ietf-httpbis-safe-meth= od-w-body-03.html#section-1-9

[3] https= ://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http

=C2=A0

=C2=A0


--

---
Josh Cohen=C2=A0

<= /div>
--000000000000774592061e19e77f--