On the harm of adding new methods

From: Larry Masinter (masinter@parc.xerox.com)
Date: Wed, Jun 10 1998


From: "Larry Masinter" <masinter@parc.xerox.com>
To: "Josh Cohen" <joshco@microsoft.com>
Cc: <ipp@pwg.org>, <ietf-http-ext@w3.org>
Date: Wed, 10 Jun 1998 08:46:39 PDT
Message-ID: <000f01bd9486$f504c160$aa66010d@copper.parc.xerox.com>
Subject: On the harm of adding new methods

There are two functions of a proxy: filtering and forwarding.
A filter decides whether or not to accept a request, and a forwarder
actually forwards the request and processes the result; forwarding
implements caching, protocol translation, tunneling, while filtering
is generally a binary "allowed" or "not allowed". There are some
forwarders that do rewriting in lieu of filtering (allow but modify).

Forwarders MUST actually understand methods, because -- unfortunately --
the meaning of HTTP headers and responses differ based on the method
of the request (e.g., Content-Length for HEAD vs GET). Many forwarding
systems will not accept new methods gracefully. 

"Forwarding" includes a wide variety of mechanisms of tunneling,
proxying, caching, distributed caching, and is a large industry.
Many of the forwarding proxies do NO filtering at all: they're there
for improving performance and reliability.

Any new METHOD in HTTP is a serious modification to the protocol, because
the forwarding function must be aware of it. A new content-type, however,
can be as easily recognized in the filter layer as a new method, but
requires NO changes to the forwarding function. Many filters already filter
on content-type anyway.

In the case of IPP, it is perfectly adequate to filter on content-type,
since all IPP content is carried in application/IPP. The arguments for 
adding a new method (that it is somehow 'easier' to filter on the first
few bytes of the protocol) are specious because most filters that are
looking at the protocol at all are looking at content-type. So the
"firewall filtering" rationale just doesn't hold as a reason for adding
new methods.

Larry
--
http://www.parc.xerox.com/masinter