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_at_eea.europa.eu> 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
>
Received on Wed Nov 10 2010 - 11:57:32 MST
This archive was generated by hypermail 2.2.0 : Wed Nov 10 2010 - 12:00:03 MST