On Fri, Apr 9, 2010 at 4:53 PM, Laurence Rowe <[email protected]> wrote: > On 10 April 2010 00:31, David Birdsong <[email protected]> wrote: >> On Fri, Apr 9, 2010 at 4:25 PM, Laurence Rowe <[email protected]> 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? > > Laurence > _______________________________________________ varnish-misc mailing list [email protected] http://lists.varnish-cache.org/mailman/listinfo/varnish-misc
