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