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

[Hariharan Sethuraman]

On Mon, 10 Sep 2018, 19:46 Amos Jeffries, <squid3 at treenet.co.nz> wrote:

> 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.
>
If I understand correctly, you are saying the caching will not be done on
squid as the content is authorised by the specific client. We can't do
anything until I ask site owners to change cache control as public?

>
>
> > -   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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20180910/9caa3430/attachment.html>