Re: Proxy code size.

From: David S. Madole <[email protected]>
Date: Wed, 11 Aug 1999 21:15:58 -0400

Jason Ackley wrote:
>
> On Wed, 11 Aug 1999, James A. Donald wrote:
>
> > My conjecture is:
> > A caching proxy attempts to be transparent,
>
> Only if it is told to..

Unless you are doing filtering, a caching proxy always tries to be
transparent... to the user. A user should not be able to tell whether
they are using a proxy or not (unless they configured the browser to
use it themselves).

> > In general this cannot be done, and there is no short
> > finite set of rules that if followed will yield
> > an acceptable simulation.
>
> RFCs are normally what squid is coded to , while they are finite at
> times, they are constantly updated / added / revised..

The statement was not made about the RFCs, it was made about the non-
existant set of theoretical rules that will cause a cache to behave
perfectly, i.e. transparently to the user. RFCs are an ideal, or at
best, an approximation of these rules, because all the other things
in the universe, like HTTP servers and browsers, do not always follow
the rules. The fact that RFCs are constantly updated, added, and
revised attests to the statement that there is no short finite set
of rules for how a cache should be implemented.

> > The writer of a caching proxy encounters an unending stream
> > of unforeseen and unexpected cases, which he must deal with
> > as best he can, with the result that the code of a caching
> > proxy tends to grow without limit.
>
> You are forgetting ICP, cache digests, ACLs, FileIO stuffs and alot of the
> other features that are needed to make a proxy fast and scaleable..This
> tends to lead to code growth more than putting in hooks for broken
> browsers..

I think the problem is much more with broken servers and broken object
content and meta data than with browsers, resulting in a lot of guesses
and approximations to reasonable sets of expiration and refresh rules,
and outright hacks, such as the "/cgi-bin/" kludge. Conflicting uses
and definitions of cache-related headers and meta data, like content
authors expeccting META tags in HTML to be interpreted by caches, rather
than by the server, make things difficult to fix, especially when some
browsers do implement things like this that they shouldn't have.

David
Received on Wed Aug 11 1999 - 19:04:11 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:47:56 MST