<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Mon, 10 Sep 2018, 19:46 Amos Jeffries, <<a href="mailto:squid3@treenet.co.nz" target="_blank" rel="noreferrer">squid3@treenet.co.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/09/18 12:18 AM, Hariharan Sethuraman wrote:<br>
> Hi All,<br>
> <br>
> I have two things to clarify:<br>
> 1) In earlier email (snipped below), Amos told that is caching and<br>
> scheduled to download<br>
<br>
Thats not what I wrote. There is data and it is scheduled for removal<br>
(erase) as soon as the current client gets responded to. It is<br>
specifically *not* caching.<br>
<br>
That confirms why you are not seeing anything in the disk cache.<br>
<br>
> - does it mean that we got the answer and do some<br>
> override?<br>
<br>
<br>
> --------------------<br>
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- <br>
>>     This is what I see when the download is in progress:<br>
>> <br>
>>     KEY 44000000000000000902000000000000<br>
>>             STORE_PENDING NOT_IN_MEMORY SWAPOUT_NONE PING_DONE<br>
>>             RELEASE_REQUEST,DISPATCHED,PRIVATE,VALIDATED<br>
> <br>
> So file stored in memory and scheduled for removal. <br>
> --------------------<br>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br>
>  <br>
> 2) With more debug_options enabled, I see that it is not caching because<br>
> the response is part of authenticated flow. Is there a way I can<br>
> override this?<br>
<br>
No. The server is supplying sufficient headers for caching to make it<br>
appear that the site authors intentionally are sending what does get<br>
delivered.<br></blockquote></div></div><div dir="auto">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?</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
> -   Initially when this file download starts, it gets authorized (I<br>
> think that is why I see HEAD request is sent to target which has<br>
> Cache-Control: max-age=0) and then the subsequent GET requests (dont<br>
> have any cache-control header) download the chunk using adjusted range<br>
> and offset.<br>
<br>
Client delivered Cache-Control do not matter. It is the *server*<br>
Cache-Control which matters here.<br>
<br>
The client can also *not* send the authentication header. That would let<br>
Squid cache the object IF the server sent this same object without<br>
credentials being needed.<br>
<br>
<br>
> -   But the subsequent GET reply seems set with auth flag, see the code<br>
> below snipped from source<br>
> (<a href="https://github.com/squid-cache/squid/blob/4f1c93a7a0d14eec223e199275ce570d840f71bc/src/http.cc" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/squid-cache/squid/blob/4f1c93a7a0d14eec223e199275ce570d840f71bc/src/http.cc</a>). <br>
>         // RFC 2068, sec 14.9.4 - MUST NOT cache any response with<br>
> Authentication UNLESS certain CC controls are present<br>
>     // allow HTTP violations to IGNORE those controls (ie re-block<br>
> caching Auth)<br>
>     if (request && (request->flags.auth || request->flags.authSent)) {<br>
>         if (!rep->cache_control)<br>
>             return decision.make(ReuseDecision::reuseNot,<br>
>                                  "authenticated and server reply missing<br>
> Cache-Control");<br>
> -   I tried adding override-expire in the cgi-bin refresh pattern, but<br>
> that will override only for max-age in Cache-control but not relevant<br>
> for auth flag.<br>
<br>
Indeed. It also will only do anything for certain outdated dynamic<br>
content URLs.<br>
<br>
As far as Squid is able to tell the content was generated specifically<br>
for this authenticated user. You need the server to send Cache-Control<br>
with one of public, must-revalidate, or s-maxage which indicate that it<br>
is actually cacheable by a shared cache (ie Squid).<br>
<br>
Otherwise the object is "private", and the cache related settings are<br>
intended for a client-specific cache, such as a Browser has.<br>
<br>
<br>
<br>
Amos<br>
</blockquote></div></div></div>