Re: [squid-users] MISSes on cacheable object

On 22/04/2014 3:04 a.m., Nikolai Gorchilov wrote:
> Actually I did find another reason for non-caching of this specific
> URL - maximum_object_size default is 4 MB, while the object is about 6
> MB.
>
> While experimenting, I stumbled upon an undocumented requirement -
> maximum_object_size MUST be placed before cache_dir, Otherwise
> cacheable check fails with "too big", regardless of
> maximum_object_size value if the object size is above the default 4
> MB.
>
> I'm wondering if there are more undocumented precedence/dependencies
> like this, that can materially impact the cache effectiveness.

FWIW; Pretty much any option which pops up a warnign about violatign
HTTP on startup has some form of undocumented side effects. Violating
the protocol rules of behaviour is rarely a good idea.

 ignore-auth and ignore-private for example causes temporary caching of
objects (filling up cache space) which are promptly revalidated and
replaced on the next user or client-IP to fetch the URL.
  ** Who knows what useful content they pushed out of cache in the
process. Squid normally (without the option) caches authenticated
responses whenever it can be sure revalidation will work properly - as
instructed by the HTTP headers.

 overide-expires *decreases* caching time for objects which the HTTP
header says are supposed to cache for longer than the refresh_pattern
min-age value.

 ignore-no-cache when it existed commonly caused strange objects to be
returned to clients. Different to the ones they were trying to fetch and
sometimes even containing info intended for other users eyes only.
(Remember how people used to be able to "hack" hotmail and facebook
accounts just by logging in from the same computer?)
 ** ignore-no-store still does this.

 max-stale=N and ignore-lastmod plays funky games overriding each other
and the stale-if-error header depending on how long the object has been
in cache.

Amos
Received on Mon Apr 21 2014 - 17:04:55 MDT