Re: surrogates are not tunnels

From: Mark Nottingham (mnot@mnot.net)
Date: Thu Apr 13 2000 - 22:32:15 MDT


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/



This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:28 MST