Hi Roy,
Surrogates are network elements which act on behalf of an
origin server and either service a request from a cache or pass the
request on to the origin server. In some implementations, the
surrogates are truly tunnels when they pass the requests on, as they
pass the request on unmodified and either do not interact with the
reply (even to cache it) or are not in the data path of the reply.
You are certainly correct that gateway is an overloaded term,
as are cache and proxy. I first floated the term surrogate in order
to try to capture the flavor of "proxy" while escaping some of the
baggage. This wasn't an attempt to get out of meeting the
requirements for specific participants in an HTTP exchange, but to try
to focus on the fact that a network element acting on behalf of an
origin server had different characteristics from other participants.
It may well be that a surrogate that is implemented as a gateway
should follow the rules set forth for gateways, but there are other
possible implementations and other issues which are less understood.
If you have followed the IETF list over the past burst of
traffic related NECP, you will have seen a lot of comments indicating
that hosts acting on behalf of origin servers are a "local matter" and
not subject to standardization. That may be, but I believe we need to
engage in some pretty thorough study of exactly how they interact with
other potential participants in the HTTP request/response stream.
Mark Nottingham of Akamai has a paper entitled "On Defining a Role for
Demand-Driven Surrogate Origin Servers" at the next WCW, and you
may want to talk to him about his take on the issue as well.
regards,
Ted Hardie
>
> 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.
>
> HTTP defines these things as "gateways". While I understand the
> reluctance to use such an overloaded term, there is no way to avoid
> including all aspects of an HTTP-to-HTTP gateway when defining this
> new term, unless you want to add more restrictive requirements
> (such as: "surrogates" only applies to HTTP-to-HTTP gateways, or
> perhaps only non-transforming HTTP-to-HTTP gateways).
>
> 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.
>
> ...........................................................................
> 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