Subject: surrogates are not tunnels

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 12 Apr 2000 17:23:37 -0700

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                                         [email-masked]
eBuilt, Inc.                                            tel:+1.949.609.0000
2652 McGaw Ave.                                         fax:+1.949.609.0001
Irvine, CA 92614-5840   USA                           http://www.eBuilt.com
...........................................................................

---

From: [email-masked]
Date: Wed, 12 Apr 2000 18:05:42 -0700 (PDT)

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

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 12 Apr 2000 22:02:44 -0700

> 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.

> 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/

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 13 Apr 2000 18:49:54 -0700

> (nominated by the master origin server, appears as an origin server to its

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.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 13 Apr 2000 21:32:15 -0700

On Thu, Apr 13, 2000 at 06:49:54PM -0700, Roy T. Fielding wrote:

> 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.

Well said. I'd go further to summarise:

* both user-agents and proxies are clients.
* proxies, gateways and origin-servers are servers.
* proxies and clients may implement a cache.

Correct?

I'm putting forward the notion that the (proxy | client) + cache
relationship is designed for and well understood, while the (origin server |
gateway) + cache relationship is not. Things are further muddied by the fact
that a surrogate is gateway + cache + client.

> 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.

The specification makes very little distinction in requirements between a
proxy and a gateway. Most distinctions are either a) requirements for
proxies that are absent for gateways or b) noting that a gateway can be used
to translate to a different protocol (which is probably the most widely used
meaning of gateway, even if they can be used HTTP->HTTP). 

The requirements for caches presuppose that they act on behalf of a client
(i.e., in a user-agent or a proxy). A gateway cache is populated on behalf
of the origin server, and operates in a very different context.

There are a lot of broken implementations out there, mostly caused by people
leveraging proxy/cache software as a demand-driven surrogate, without
considering the protocol implications. While some of this could be avoided
by a careful reading of the spec as to the difference between 'proxy' and
'gateway', in many places it's not clear, or complete. There's also a fair
amount of pressure to add protocol features specific to the unique situation
a surrogate is in.

IMHO, this leads to the need for clearer requirements for such a device; one
way of doing so may be to create a new role for it. A sizeable amount of
internet traffic now flows through surrogates, and if some reports are to be
believed, that proportion will only increase in the future.

Cheers,

-- 
Mark Nottingham
http://www.mnot.net/

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 13 Apr 2000 23:02:50 -0700

> * both user-agents and proxies are clients.

As are HTTP-to-HTTP gateways -- they act as a client for their interaction
with the inbound (origin) servers.  HTTP-to-OTHER gateways are also
clients, but in that case they only have to obey the OTHER protocol's
client requirements.  In many cases, this OTHER protocol is just a
private company's bastardized HTTP for their internal purposes.

> * proxies and clients may implement a cache.

Anything except a tunnel (while acting as a tunnel) can implement a cache.
 
> that a surrogate is gateway + cache + client.

I disagree.  While there is certainly more to learn out there regarding
all aspects of the Web architecture, these surrogate things were both
known about and planned for in HTTP/1.1.  In fact, that is most of the
planning I did for 1.1 -- making the message rules such that any
intermediary can process a message without necessarily knowing all
of the semantics of the message.  This was the key to enabling
hierarchical cache mechanisms, which was my goal at the time, and
it applied to both incoming request streams (proxy hierarchies)
and outgoing response steams (server-side cache distribution networks).

That isn't to say that HTTP/1.1 gets everything right by any means,
but this part was pretty well understood at the time (late 1994/1995).
Most of the problems that remain in HTTP/1.1 are things that we
couldn't fix without breaking backwards-compatibility with HTTP/1.0.

>... 

Oh, there is definitely room for additional requirements and protocol
extensions for managed cache control, and even for newer, more efficient
standards for those OTHER protocols.  What I was objecting to was the
statement (in the taxonomy) which says the "requirements for surrogates
have not been standardized."  That statement is false for HTTP.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 13 Apr 2000 23:38:44 -0700

> have not been standardized."  That statement is false for HTTP.

OK, that sounds like a good piece of common ground to start with. I'd agree
that the basic requirements within the framework of a gateway are valid and
applicable to a surrogate.

I've noted both problems with current implementations (mostly caused by
misuse of proxy software, but also a few brought about by ambiguity in the
protocol) and opportunities for making a surrogate more efficient; this is
the bulk of what I intend to present.

This has been very helpful in clarifing the issues; thanks.

-- 
Mark Nottingham
http://www.mnot.net/

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 14 Apr 2000 07:33:19 +0200

> * proxies and clients may implement a cache.

Att kinds of servers may implement a cache, especially gateways.

--
Henrik Nordstrom