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

[Hariharan Sethuraman]

Also can I achieve using reply_header_replace directive? I know it is
violation, just to understand the available options.

On Mon, 10 Sep 2018, 19:57 Hariharan Sethuraman, <srnhari at gmail.com> wrote:

>
>
> 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/a6887610/attachment.html>