On 18/02/2017 9:31 a.m., Alex Rousskov wrote: > On 02/17/2017 01:27 PM, Heiler Bemerguy wrote: >> Em 17/02/2017 17:05, Alex Rousskov escreveu: >>> On 02/17/2017 12:31 PM, Heiler Bemerguy wrote: >>>> I've noticed this: >>>> >>>> 2017/02/17 16:28:05.632 kid4| ctx: enter level 0: >>>> 'http://personal.avira-update.com/update/idx/localdecider_sigver-win32-int-13.0.1.12.info.lz' >>>> 2017/02/17 16:28:05.632 kid4| 22,3| http.cc(339) cacheableReply: NO >>>> because e:=p2XDIV/0x15c49190*3 has been released. >>>> 2017/02/17 16:28:05.797 kid4| ctx: enter level 0: >>>> 'http://personal.avira-update.com/update/idx/weblocaldecider_sigver-win32-int-15.0.15.28.info.lz' >>>> 2017/02/17 16:28:05.797 kid4| 22,3| http.cc(339) cacheableReply: NO >>>> because e:=p2XDIV/0x15c49190*3 has been released. >>>> 2017/02/17 16:28:17.803 kid4| ctx: enter level 0: >>>> 'http://personal.avira-update.com/update/x_vdf_sigver/7.12.155.132_8.12.155.132/aevdf.dat.lz' >>>> 2017/02/17 16:28:17.803 kid4| 22,3| http.cc(339) cacheableReply: NO >>>> because e:=p2XDIV/0x6a233d0*3 has been released. >>>> >>>> It seems I'm not caching it too, but couldn't understand what "has been >>>> released" is referring too. >>> In this debugging context, "has been released" means that the response >>> was marked for removal from the cache some time earlier. It will be >>> delivered to the current client (or several concurrent clients in some >>> cases) but it will not be available to future clients. > >>> These debugging lines do not tell us why or when that marking was >>> applied. It is possible that the response had some anti-caching >>> Cache-Control headers or was too big to cache, but these are just two >>> examples; there are lots of other possible reasons. > >> When you say "some time earlier", you mean days? > > Usually seconds or milliseconds (but, in theory, it could be a lot > longer than that, even days). > > >> I was using ALL,3 and cat cache.log |grep -C 10 avira-update |grep kid2 > > Sorry, I do not have enough information to answer "why" or "when". > Others on the list may be able to guide you further. > I usually point people to redbot.org at this point. But the report there says the URL is cacheable so long as one is not using If-None-Match headers. So it is not something the server is preventing, although ~5 min is a rather short TTL. PS. The 'splicelid' person is showing access.log entries that indicate they are intercepting traffic. So the Host-verify feature may be involved with marking the objects as unsafe to cache. Avira was one company I had a rather difficult discussion with about how their AV client was using the Host header. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
