|
Amos, thanks for your answer. I understand your point in
collapsed_forwarding not being triggered because the requests are
not concurrent, nevertheless if I use collapsed_forwarding the Vary
loop appears, if I disable it, format the cache_dir and start over
.. It does not appear. If you think I could do something else to debug this I'll be glad to do it. For now I've disabled collapsed_forwarding in my production servers and everything looks good Regards, Sebastian El 15/09/15 a las 07:37, Amos Jeffries
escribió:
On 15/09/2015 9:16 a.m., Sebastián Goicochea wrote:I could finally isolate the problem, it only happens if you are using collapsed_forwarding. If you want, you can use this script to replicate it: #!/bin/bash H='--header' echo "With Firefox" wget -d \ $H='Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' \ $H='Accept-Encoding: gzip, deflate' \ $H='Accept-Language: en-us,en;q=0.5' \ $H='Cache-Control: max-age=0' \ $H='Connection: keep-alive' \ -U 'Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2' \ -O /dev/null \ $1 echo "With Chrome" wget -d \ $H='Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8'\ $H='Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3'\ $H='Accept-Encoding:gzip,deflate,sdch'\ $H='Accept-Language:es-ES,es;q=0.8'\ $H='Cache-Control:no-cache'\ $H='Connection:keep-alive'\ $H='Pragma:no-cache'\ -U 'User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.32 (KHTML, like Gecko) Chrome/27.0.1425.0 Safari/537.32 SUSE/27.0.1425.0'\ -O /dev/null \ $1 # End of script script usage: ./wgets.sh http://www.clarin.com/external-images/GranDTUnificada_5729dd7a1487678526c23516a5083661.jpgThat script is not doing what you think it is. The requests are being made in series with the first one finishing before the second starts. Your access.log timing confirms that with a whole 18ms between the two requests. So I dont think this script is actually triggering the collapsed forwarding behaviour. Or it should not be if it is. Also, look closely for the "\r\n" between headers. [User-Agent: Wget/1.12(linux-gnu)\r\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8--header=Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3--header=Accept-Encoding:gzip,deflate,sdch--header=Accept-Language:es-ES,es;q=0.8--header=Cache-Control:no-cache--header=Connection:keep-alive--header=Pragma:no-cache-U\r\nHost: www.clarin.com\r\nConnection: Keep-Alive\r\n]cache.log output: 2015/09/14 14:05:01 kid1| clientProcessHit: Vary object loop! 2015/09/14 14:05:27 kid1| varyEvaluateMatch: Oops. Not a Vary match on second attempt, 'http://www.clarin.com/external-images/GranDTUnificada_5729dd7a1487678526c23516a5083661.jpg' 'accept-encoding="gzip,%20deflate", user-agent="Mozilla%2F5.0%20(Windows%20NT%205.1%3B%20rv%3A10.0.2)%20Gecko%2F20100101%20Firefox%2F10.0.2"' 2015/09/14 14:05:27 kid1| clientProcessHit: Vary object loop! 2015/09/14 14:05:27 kid1| varyEvaluateMatch: Oops. Not a Vary match on second attempt, 'http://www.clarin.com/external-images/GranDTUnificada_5729dd7a1487678526c23516a5083661.jpg' 'accept-encoding, user-agent="Wget%2F1.12%20(linux-gnu)"' 2015/09/14 14:05:27 kid1| clientProcessHit: Vary object loop!What do you think? Is this the expected behaviour?There is something slightly odd. I'm not sure if its wrong exactly, but definitely odd. Its not clear if the cache.log output is from the first or second request. I assume (big IF) that above cache.log is the first one finding some prior Firefox entry, then the second one finding the first ones entry. Its very weird that the second one gets "Not a Vary match". The lookups should have been the same regardless of your script breakage. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users |
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
