[squid-users] Squid 4.2 : caching is not working

[Amos Jeffries]

On 11/09/18 12:18 AM, Hariharan Sethuraman wrote:
> Hi All,
> 
> I have two things to clarify:
> 1) In earlier email (snipped below), Amos told that is caching and
> scheduled to download

Thats not what I wrote. There is data and it is scheduled for removal
(erase) as soon as the current client gets responded to. It is
specifically *not* caching.

That confirms why you are not seeing anything in the disk cache.

> - does it mean that we got the answer and do some
> override?


> --------------------
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 
>>     This is what I see when the download is in progress:
>> 
>>     KEY 44000000000000000902000000000000
>>             STORE_PENDING NOT_IN_MEMORY SWAPOUT_NONE PING_DONE
>>             RELEASE_REQUEST,DISPATCHED,PRIVATE,VALIDATED
> 
> So file stored in memory and scheduled for removal. 
> --------------------
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>  
> 2) With more debug_options enabled, I see that it is not caching because
> the response is part of authenticated flow. Is there a way I can
> override this?

No. The server is supplying sufficient headers for caching to make it
appear that the site authors intentionally are sending what does get
delivered.


> -   Initially when this file download starts, it gets authorized (I
> think that is why I see HEAD request is sent to target which has
> Cache-Control: max-age=0) and then the subsequent GET requests (dont
> have any cache-control header) download the chunk using adjusted range
> and offset.

Client delivered Cache-Control do not matter. It is the *server*
Cache-Control which matters here.

The client can also *not* send the authentication header. That would let
Squid cache the object IF the server sent this same object without
credentials being needed.


> -   But the subsequent GET reply seems set with auth flag, see the code
> below snipped from source
> (https://github.com/squid-cache/squid/blob/4f1c93a7a0d14eec223e199275ce570d840f71bc/src/http.cc). 
>         // RFC 2068, sec 14.9.4 - MUST NOT cache any response with
> Authentication UNLESS certain CC controls are present
>     // allow HTTP violations to IGNORE those controls (ie re-block
> caching Auth)
>     if (request && (request->flags.auth || request->flags.authSent)) {
>         if (!rep->cache_control)
>             return decision.make(ReuseDecision::reuseNot,
>                                  "authenticated and server reply missing
> Cache-Control");
> -   I tried adding override-expire in the cgi-bin refresh pattern, but
> that will override only for max-age in Cache-control but not relevant
> for auth flag.

Indeed. It also will only do anything for certain outdated dynamic
content URLs.

As far as Squid is able to tell the content was generated specifically
for this authenticated user. You need the server to send Cache-Control
with one of public, must-revalidate, or s-maxage which indicate that it
is actually cacheable by a shared cache (ie Squid).

Otherwise the object is "private", and the cache related settings are
intended for a client-specific cache, such as a Browser has.



Amos