Re: Proxy code size.

David S. Madole writes:
> 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).

First, IMHO "transparent proxy" is a term of art, used when referring
specifically to the use of a proxy without specific configuration by
the user, via TCP packet redirection. Most proxies are still deployed
in the usual "non-transparent" mode, requiring the browser to be
specifically configured for the proxy, so there is some user visibility.

Second, there are all sorts of conditions under which a proxy will
behave differently from a non-proxied connection, and where this is
considered acceptable behavior. To take a couple of the obvious ones,
specifying a non-existent host name in a URL, or putting in an invalid
path component in a URL will or may behave differently in a proxied
connection than a non-proxied connection.

Again IMHO, defining "transparent" as what caching proxies try to be is
something of a straw man.

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

That's very true. It's also true, though, that many reports do get met
with "That server's broken; tell the administrators to fix it." Looking
at what you list suggests that what a proxy such as Squid is really
trying to implement is more on the order of:

  an *exact* replication of the behavior which would be seen *if*
  talking to fully RFC-compliant browsers and fully RFC-compliant
  servers delivering content labelled in fully RFC-compliant ways;

  and a "reasonable approximation" of the real-world behavior seen when
  either the browser or the server or both is non-RFC-compliant, or
  when the content is not labelled in RFC-compliant ways.

  -- Clifton

-- 
 Clifton Royston  --  LavaNet Systems Architect --  cliftonr@lava.net
        "An absolute monarch would be absolutely wise and good.  
           But no man is strong enough to have no interest.  
             Therefore the best king would be Pure Chance.  
              It is Pure Chance that rules the Universe; 
          therefore, and only therefore, life is good." - AC