On Mon, 10 Sep 2018, 19:46 Amos Jeffries, <squ...@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 >
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
