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

  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.

In thinking about what you may have meant by this: this seems to make
some amount of sense for incoming requests.  But it doesn't seem to
make so much sense for outgoing requests, unless your model is that a
firewall is there to protect the rest of the world from your internal
network.

So it might work if you were able to configure proxies to accept
only certain methods from the outside world (if you cared), while also
being able to configure them to be transparent for outgoing requests.

I'm trying to imagine security reasons for this level of worry.  It
seems no worse to me allow extension methods to come in from outside
than to allow CGI scripts in one's internal network.  It also seems
that, as with CGI scripts, the appropriate control point is the
(origin) HTTP server. In either case there must be some program
running in the internal network to implement the script or method, and
you can potentially do just as much damage with a script triggered by
GET or POST as with a method called DELETE-ALL-FILES.

In further response to the last point you made above, I prefer the
model where the intermediate servers have only minimal knowledge of
the semantics of the request and response. They only really need to
know how the request and response can respectively be fetched from or
stored into a cache, and other caching side effects. And we have
header meta-information to control that (plus some built-in meta-
information such as the list of standard methods whose responses can
be fetched from a cache).  Maybe that is naive but I
have to admit I don't see how.

Of course as Andrew pointed out this kind of extensibility is limited
in any case to that which can use the same underlying transport
mechanism.

Received on Sunday, 10 September 1995 21:37:37 UTC