W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

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

From: Balint Nagy Endre <bne@bne.ind.eunet.hu>
Date: Mon, 11 Sep 1995 05:12:22 +0200 (MET DST)
To: Shel Kaphan <sjk@amazon.com>
Cc: http wg discussion <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <20.bne@bne.ind.eunet.hu>
Shel Kaphan (in reply to Roy Fileding) writes:
> The HTTP spec says (and I take this from the HTTP 1.1 spec dated
> 8/27/95, but it hasn't changed any time lately):
> In "5.2 Method":
> 	"The set of common methods for HTTP/1.1 is described below
> 	Although this set can be easily expanded, additional methods cannot be
> 	assumed to share the same semantics for separately extended clients
> 	and servers."
> This clearly implies that the spec allows that there will be some
> "ad hoc" experimentation and extension of the protocol going on in the world.
The PLAY/STREAM method already discussed (and likely rejected) on thist
list. A such method surely can't be forwarded by a proxy, not implementing
the method. (Under IP this method may be hard or impossible to implement,
but under ST2 (see RFC1819) it can be done relatively easy, ST2 will do the 
complex job of timely delivery of data. But ST2 is still an experimental 
protocoll and every active element between the client and the server must
implement ST2 to participate in experiments.)
Even if PLAY method never appears again, some other methods may be 
non-forwardable by 1.0 or 1.1 proxies.
This is the motivation for intoducing the versioning scheme, I proposed
> People behind firewalls do not have a choice of whether their client
> talks to a proxy or an origin server, so by disallowing proxies to
> forward methods they do not explicitly recognize, you have made the
> semantics of what happens when a method request is issued dependent on
> whether you are talking to a proxy or an origin server.  
Proxies, running on a firewall machine require more precious control, 
than "simple" proxies. Such specially designed proxies should have
configuration options to allow forwarding every extension method 
individually, even if my versioning scheme will not remain an idea only.
(Application gateways, installed on firewalls should never trust even
hosts on the protected network.)
> Also in "5.2 Method":
> 	"Servers should return ... 502 (not implemented) if the method
> 	is unknown or not implemented by the server".
> I think an exception needs to be made for intermediate proxies.  It
> seems to me they should not preemptively claim to know what the origin
> server does and does not support.
I think, exceptions *may* be enabled, but *must* be controlled in a
reasonable way. I'm still unsure, my idea (based on your idea) is worth 
the efforts, required to specify it fully.

Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>
Received on Sunday, 10 September 1995 21:06:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:15 UTC