[squid-users] Objects with values below 60 second for Cache-Control max-age are not cached

[Amos Jeffries]

On 26/10/2016 7:21 p.m., Garri Djavadyan wrote:
> On Wed, 2016-08-24 at 19:09 +0500, Garri Djavadyan wrote:
>> On Mon, 2016-08-22 at 16:46 +0500, Garri Djavadyan wrote:
>>>
>>> Hello Squid users,
>>>
>>> Can anyone explain, why Squid doesn't cache the objects with max-
>>> age
>>> values below 60 seconds?

Several possible reasons...

> For example:
>>>
>>> $ http_proxy="127.0.0.1:3128" curl --head "http://sandbox.comnet.lo
>>> ca
>>> l/
>>> cgi-bin/hello.cgi" && date
>>> HTTP/1.1 200 OK
>>> Date: Mon, 22 Aug 2016 11:31:16 GMT
>>> Server: Apache
>>> Cache-Control: max-age=60
>>> Content-Type: text/plain
>>> X-Cache: MISS from gentoo.comnet.uz
>>> Via: 1.1 gentoo.comnet.uz (squid/3.5.20)
>>> Connection: keep-alive
>>>
>>> Mon Aug 22 16:31:19 UZT 2016
>>>

1) This is not a GET request.

There is no object data returned on a HEAD request. So Squid does not
have anything to cache.

If you did a GET before this request, then the caching time is relative
to that request, not this one.


2) There is no Last-Modified header.

Squid older than 3.5.22 do not revalidate properly with only a Date
header. Meaning new content is required fetching if the cached object
was stale.

3) The response to a HEAD request is supposed to be the headers that
would be sent in an equivalent GET. So the servers upstream response
headers are the right output here in light of (2) and/or (1).

>>> ---
>>>
>>> $ http_proxy="127.0.0.1:3128" curl --head "http://sandbox.comnet.lo
>>> ca
>>> l/
>>> cgi-bin/hello.cgi" && date
>>> HTTP/1.1 200 OK
>>> Date: Mon, 22 Aug 2016 11:31:23 GMT
>>> Server: Apache
>>> Cache-Control: max-age=60
>>> Content-Type: text/plain
>>> X-Cache: MISS from gentoo.comnet.uz
>>> Via: 1.1 gentoo.comnet.uz (squid/3.5.20)
>>> Connection: keep-alive
>>>
>>> Mon Aug 22 16:31:26 UZT 2016
>>>
>>>
>>> No problems with values above 60 seconds. For example:
>>>
>>> $ http_proxy="127.0.0.1:3128" curl --head "http://sandbox.comnet.lo
>>> ca
>>> l/
>>> cgi-bin/hello.cgi" && date
>>> HTTP/1.1 200 OK
>>> Date: Mon, 22 Aug 2016 11:36:06 GMT
>>> Server: Apache
>>> Cache-Control: max-age=70
>>> Content-Type: text/plain
>>> X-Cache: MISS from gentoo.comnet.uz
>>> Via: 1.1 gentoo.comnet.uz (squid/3.5.20)
>>> Connection: keep-alive
>>>
>>> Mon Aug 22 16:36:09 UZT 2016
>>>
>>> ---
>>>
>>> $ http_proxy="127.0.0.1:3128" curl --head "http://sandbox.comnet.lo
>>> ca
>>> l/
>>> cgi-bin/hello.cgi" && date
>>> HTTP/1.1 200 OK
>>> Date: Mon, 22 Aug 2016 11:36:06 GMT
>>> Server: Apache
>>> Cache-Control: max-age=70
>>> Content-Type: text/plain
>>> Age: 5
>>> X-Cache: HIT from gentoo.comnet.uz
>>> Via: 1.1 gentoo.comnet.uz (squid/3.5.20)
>>> Connection: keep-alive
>>>
>>> Mon Aug 22 16:36:11 UZT 2016
>>>
>>>
>>> As you can see, time difference between origin server and localhost
>>> is
>>> 3 seconds (UZT is +5 offset).

Your interpretation of the timestamps is flawed.

The message header contains teh timestamp the servre generated teh message.
The 'date' tool produces the timestamp at teh time the transaction
delivering it was completed.

All that is evident is that the transaction took ~5 seconds from message
generation to completion of delivery. That may contain any amount of +N
or -N difference in the three machines clocks (server, proxy, and client).

...


>>>
>>> Configuration is minimal:
>>>
>>> # diff -u etc/squid.conf.default etc/squid.conf
>>> --- etc/squid.conf.default	2016-08-12 17:21:48.877474780
>>> +0500
>>> +++ etc/squid.conf	2016-08-22 16:41:47.759766991 +0500
>>> @@ -71,3 +71,5 @@
>>>  refresh_pattern ^gopher:	1440	0%	1440
>>>  refresh_pattern -i (/cgi-bin/|\?) 0	0%	0
>>>  refresh_pattern .		0	20%	4320
>>> +
>>> +cache_mem 64 MB
>>>
>>>
>>> Thanks in advance!
>>> Garri
>>
>> Dear Squid developers,
>>
>> Is the situation described above intended behaviour, or a bug which
>> should be reported? Thanks.
>>
>> Garri
> 
> Squid debugging led me to:
> http://www.squid-cache.org/Doc/config/minimum_expiry_time/
> 

HTTP requires a full second resolution of time, no shorter due to clock
skew across the length and breadth of the Internet. And for the same
reason 60sec resolution on caching is recommended for best response
accuracy if any type of long-distance exists between servers and proxy.

Amos