> > The implementation requirements for HTTP-aware "surrogates" have been
> > standardized. They are all the requirements for gateways in HTTP.
> > Changing the name doesn't change those requirements. Changing the name
> > doesn't make the currently broken implementations of "reverse proxies"
> > any more compliant with HTTP.
>
> "Gateway" may provide a very general framework for requirements (such as
> message and connection handling, etc), but this completely ignores the fact
> that a surrogate (or at least, a demand-driven surrogate, to use the
> taxonomy's language) implements a cache, or the context that it operates in
> (nominated by the master origin server, appears as an origin server to its
> clients).
How does it ignore it? The HTTP specifications (going back to
October 1995) include overlapping requirements for each role portrayed
by some piece of compliant software: client/server, cache/no-cache,
and user-agent/proxy/gateway/origin-server. By your description,
a demand-driven surrogate is defined by HTTP as a gateway (implying
both client and server requirements along with the requirements on
an intermediary) with an optional cache. Both the semantic and
protocol syntax requirements for such a beast are fully defined by
HTTP/1.1. What is not defined is the administration framework and
such protocol additions required to dynamically manipulate the
arrangement of such beasts, since that was outside the scope of
the HTTP communication path itself.
As a reminder, here are the definitions from RFC 2616:
gateway
A server which acts as an intermediary for some other server.
Unlike a proxy, a gateway receives requests as if it were the
origin server for the requested resource; the requesting client
may not be aware that it is communicating with a gateway.
tunnel
An intermediary program which is acting as a blind relay between
two connections. Once active, a tunnel is not considered a party
to the HTTP communication, though the tunnel may have been
initiated by an HTTP request. The tunnel ceases to exist when both
ends of the relayed connections are closed.
cache
A program's local store of response messages and the subsystem
that controls its message storage, retrieval, and deletion. A
cache stores cacheable responses in order to reduce the response
time and network bandwidth consumption on future, equivalent
requests. Any client or server may include a cache, though a cache
cannot be used by a server that is acting as a tunnel.
...........................................................................
Roy T. Fielding fielding@ebuilt.com
eBuilt, Inc. tel:+1.949.609.0000
2652 McGaw Ave. fax:+1.949.609.0001
Irvine, CA 92614-5840 USA http://www.eBuilt.com
...........................................................................
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:28 MST