- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Wed, 10 Jun 1998 08:46:39 PDT
- To: "Josh Cohen" <joshco@microsoft.com>
- Cc: <ipp@pwg.org>, <ietf-http-ext@w3.org>
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
Received on Wednesday, 10 June 1998 11:52:18 UTC