different object hashed for firefox and chrome
david.birdsong at gmail.com
Sat Apr 10 02:23:51 CEST 2010
On Fri, Apr 9, 2010 at 4:53 PM, Laurence Rowe <l at lrowe.co.uk> wrote:
> On 10 April 2010 00:31, David Birdsong <david.birdsong at gmail.com> wrote:
>> On Fri, Apr 9, 2010 at 4:25 PM, Laurence Rowe <l at lrowe.co.uk> wrote:
>>> This is almost certainly the result of a Vary: Accept-Encoding header
>>> on your response (Chrome, Firefox and IE all have slightly different
>>> Accept-Encoding headers). See
>>> http://varnish-cache.org/wiki/FAQ/Compression and add the snippet to
>>> normalise the Accept-Encoding header in vcl_recv. You don't normally
>>> need to customise vcl_hash.
>> thanks for that link. i've customized vcl_hash to exclude
>> req.http.host which i dont want as part of the hash. my understanding
>> was that this was included by default.
> It may be better to set req.host to a canonical value in vcl_recv,
> that way you can be sure that your backends will always produce
> consistent responses (so you don't end up with some urls pointing to
> http://example.com and others to http://example.org).
> My point was rather that the requests still hash the same, you're
> getting a different object on Vary. vcl_hash lets you set the cache
> path based only on the request, vcl_fetch and Vary let you set the
> cache path further based on the response. It's not yet shown on the
> flowchart at http://varnish-cache.org/wiki/VCLExampleDefault.
so how is that cache path that is set in vcf_fetch based on response
reached after the object is stored and then re-requested?
More information about the varnish-misc