I see ... My eyes stopped at \r\n :)
It's worth mentioning that other tools and even another proxy that I've
tested (varnish) are parsing the Vary header and eliminate spaces, tabs,
line-brakes and even multiple occurrences of the same header name in
Vary; for my case the two texts are considered equivalent by varnish and
it is NOT invalidating the other variants.
Perhaps something worth doing for squid too? I mean, it's obviously not
a squid bug but it will be consistent to the way developer tools
(firebug, chrome dev tools etc) are treating this header.
Adrian
On 11/10/2010 04:41 AM, Amos Jeffries wrote:
On Tue, 09 Nov 2010 17:37:55 +0200, Adrian Dascalu
<adrian.dascalu@xxxxxxxxxxxxx> wrote:
Ok, it's a bit late for me but for other people browsing this list I'm
sharing my findings:
It looks like squid is really picky about the way Vary header text is
formed: the vary headers in my case where not "identical" due to a bug
in the backed server. A header name was repeated for the anonymous users
(", Accept-encoding" added at the end of the list). Developer tools in
firefox and chrome were silently correcting this and even squid
access.log with headers (see below) was only showing an extra coma that
was difficult to spot.
Aha! great.
Hmm, squid should be logging exactly what it received (URL-encoded to
protect against binary blobs). And sure enough now that you point out what
to look for it is there...
GMT\r\nVary: Accept-Encoding, Accept,
X-Username,\r\n%09Accept-Encoding\r\nLast-Modified: Fri, 28 Nov 2008
NOTE: the "%09" or tab character folded-line .
Amos
