[squid-users] squid-avira-update-cache

[Amos Jeffries]

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