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
