Re: Method Mania

Correcting myself...  Idempotency refers to the effect on the server, not
the response to the client.  So my point about subscribe violating that
rule was incorrect.
From the connection semantics point of view, it might be worth considering
a separate method.



On Thu, Jul 25, 2024 at 3:27 PM Josh Cohen <joshco@gmail.com> wrote:

> 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
>
>

-- 

---
*Josh Co*hen