> > 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.
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, gateways and origin-servers are servers.
> * proxies and clients may implement a cache.
Anything except a tunnel (while acting as a tunnel) can 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.
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.
>...
> 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.
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.
...........................................................................
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