- From: Josh Cohen <joshco@gmail.com>
- Date: Thu, 25 Jul 2024 15:27:36 -0700
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAF3KT4QZzx+FXOUHZoy+gPqJjQ+4KdOC+_29vbUANNtZQS4c+A@mail.gmail.com>
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: <Parameters> <Parameters> 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
Received on Thursday, 25 July 2024 22:27:51 UTC