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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
