Method Mania

[Josh Cohen <[e-mail]>]

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