Re: Cacheable extension methods (was: an idempotent idea)

  >You said:
  >	A proxy cannot forward a method it doesn't understand.
  >	
  >Why not?  It seems to me this places an unnecessary limitation on the
  >protocol without reason.  (OK, you might have a reason, but you didn't
  >state it, and it isn't obvious).

  Because the semantics of the method determine whether or not the
  request contains content and/or the response contains content,

So do the message headers and/or the presence of bytes in the message
following the header.  So a server doesn't need to know what method a
request involves to determine if there is content that may also need
to be forwarded.

  and whether or not the request is intended for the immediate
  server (possibly a proxy), all servers along the request route,
  or just the origin server.

I think that if proxy can't tell whether or not a message is intended
for it by examining the URI and the method, then it should *assume*
that the method is not intended for that proxy, and rather than
preemptively reporting an error, it should forward it.  This is way
more extensible and leads to more consistent semantics.  If a
subsequent server then reports an error then that error can always be
reported back to the original requestor.

  No firewall proxy will ever forward an action that it doesn't
  know the consequences of.  In order to experiment with new methods,
  all servers along the request/response chain must have a common
  understanding of the semantics of the method.

Then an "experiment" is all it will ever be, and the extensibility of
HTTP is just toy extensibility, and can't be used in the real world. (sigh).


   ....Roy T. Fielding  Department of ICS, University of California, Irvine USA
			Visiting Scholar, MIT/LCS + World-Wide Web Consortium
			(fielding@w3.org)                (fielding@ics.uci.edu)

--Shel

Received on Sunday, 10 September 1995 21:09:52 UTC