On Wed, Apr 12, 2000 at 05:23:37PM -0700, Roy T. Fielding wrote:
> The definition of surrogate in
> http://www.ietf.org/internet-drafts/draft-ietf-wrec-taxonomy-03.txt
>
> surrogate (a.k.a. "reverse proxies", "web server accelerators")
> An intermediary program which acts as a server or tunnel for the
> purpose of responding to requests on behalf of one or more origin
> servers. Requests are serviced internally from a cache or by
> tunnelling them on to origin servers. The implementation
> requirements for surrogates have not been standardized; depending
> on the implementation, surrogates may or may not respond to the
> cache directives defined in [1] . Surrogates are also known as
> "reverse proxies" and "(origin) server accelerators".
>
> is not accurate because it refers to "tunnelling". A surrogate does
> not tunnel requests -- it forwards them. Likewise, the content may be
> transformed or redirected in the process. Note that it is impossible
> for an HTTP tunnel to cache responses.
I would agree that the wording "service internally from a cache or by
tunnelling them on to origin servers" is unfortunate, but a surrogate may
act as a gateway or a tunnel; there may be perfectly valid reasons why a
surrogate might be configured to tunnel some requests back to the master
origin server, for whatever reason.
That having been said, this would not be a typical use of a surrogate, and
the word 'tunnel' probably does more harm than good; it deserves to be a
footnote. I'd be comfortable if the section 'acts as a server... on to
origin servers' were replaced with something that established that a) a
surrogate is a gateway and b) it appears as an origin server to downstream
clients.
> 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).
I'm presenting a paper at WCW5 that attempts to motivate the establishment
of a distinct role for demand-driven surrogate origin servers, and identify
some of the problems and opportunities that they present. Hecklers welcome.
-- Mark Nottingham http://www.mnot.net/
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:28 MST