[squid-users] pages not being cached

[Amos Jeffries]

On 12/03/2016 5:51 a.m., Cindy Cicalese wrote:
>>
>>> I added the logformat command that you suggested. I needed to modify it
>>> slightly, since I'm running squid 3.1 (I changed <a to <A and removed
>>> %>eui). An example of what I am seeing in /var/log/squid/access.log is:
>>
>> The 'eui' change is okay, but to ensure the traffic is flowing through
>> the correct routes we do need to compare the IPs so 'a' is needed, not 'A'.
>>
> 
> I am running squid version 3.1.23, which is what is provided by yum with
> Red Hat 6. Per the documentation at
> http://www.squid-cache.org/Versions/v3/3.1/cfgman/logformat.html, there is
> no <a option in squid version 3.1. Is there an alternative way to get that
> information with squid version 3.1.23?

Ah. That being an old version may be part of your problem. 3.1 only
supports ~60% of HTTP/1.1 requirements.

> 
>> 1457630282.410    490 172.31.169.175 TCP_MISS/200 4621 GET
>>> https://<server>/tw4/index.php/Two
>>> - FIRST_UP_PARENT/127.0.0.1 text/html Q-CC: "max-age=0" "max-age=0" Q-P:
>>> "-" "-" REP-CC: "s-maxage=18000, must-revalidate, max-age=0" REP-EXP: "-"
>>> VARY: "-"
>>>
>>
>> The client here is requiring that the cache not be used to answer this
>> request.
>>
> 
> I had read that "Cache-Control: no-cache" indicates that caching should not
> be used to satisfy requests, but that "Cache-Control: max-age=0" only
> indicates that *client* caching should not be used. Is this not the case?

You don't have "no-cache" in those log entries. Your particular old
Squid version does not fully support no-cache subtle details anyway. So
it treats no-cache as if it were no-store.


You have Q-CC values of max-age=0. That is called "reload" in HTTP
terminology. The client overridding the REP-CC values and demanding that
the copy it gets given is no more than 0 seconds old. ie. forcing Squid
to fetch new data (MISS).

You can use the 'reload-into-ims' parameter on refresh_pattern rules to
make Squid 'reload' using a revalidation request when that pattern
matches. I think that will turn the Chrome actions into what IE is doing
below.


> 
>> Click in the address bar and press enter. Do that twice and see if the access.log
> changes. The first may or may not be a MISS. The second should be a HIT or
> REFRESH.
> 
> If it is a MISS, it continues to be a miss no matter how many times I click
> in the address bar and press enter.
> 
> However, I have found that the behavior is browser dependent:
> 
> IE - caching works:
> 
> 1457713900.951      0 <external ip> TCP_MEM_HIT/200 4634 GET https://<server
> name>
>  "s-maxage=18000, must-revalidate, max-age=0" REP-EXP: "-" VARY: "-"
> 
> Firefox - caching works:
> 
> 1457713889.563      0 <external ip> TCP_IMS_HIT/304 319 GET https://<server
> name>/tw4/index.php/Two - NONE/- text/html Q-CC: "-" "-" Q-P: "-" "-"
> REP-CC:
> "-" REP-EXP: "-" VARY: "-"
> 
> Chrome - caching does not work:
> 
> 1457713978.632    344 <external ip> TCP_MISS/304 316 GET https://<server
> name>/tw4/index.php/Two - FIRST_UP_PARENT/127.0.0.1 - Q-CC: "max-age=0"
> "max-age=
> " VARY: "-"
> 
> Is there a reason that server side caching would be browser dependent?

Notice the different Q-CC. The "working" browsers are not demanding the
Squid cache reload its stored data.

Amos