Re: Extension headers and caching

>From that page:

Only send a Vary: Accept-Encoding header when you have compressed the content (e.g. Content-Encoding: gzip).

I thought the correct behaviour was to always send Vary: Accept-Encoding if that entity
may have >1 variant. This means if you -may- or -have- compressed the content in the
reply.

ISTR Squid will delete items from the cache if it gets a response back with a different
Vary: header as the variant key match has changed and all objects cached with the previous
Vary: header list now may be invalid.




Adrian

On Tue, Feb 10, 2009, Eric Lawrence wrote:
> >IE has lots of issues with Vary
> 
> To be more specific, the WinINET networking stack does not cache outbound request headers, preventing IE and other applications from reusing resources that Vary without validation (except in narrow cases).  See http://www.fiddler2.com/fiddler/Perf/AboutVary.asp for more information.
> 
> Revalidation ensures cache-correctness but entails a performance cost.
> 
> -Eric
> 
> -----Original Message-----
> From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org] On Behalf Of Julian Reschke
> Sent: Monday, February 09, 2009 3:51 AM
> To: Anne van Kesteren
> Cc: HTTP Working Group
> Subject: Re: Extension headers and caching
> 
> 
> Anne van Kesteren wrote:
> >
> > Hi,
> >
> > If I perform a request to a server and then perform a subsequent request
> > with an extension header set, should I get a cached copy or a fresh one
> > for the subsequent request? Would it be different if the server had
> > replied with a Vary header for the extension header?
> 
> IMHO:
> 
> if the response to the first request *was* cacheable, and the server
> varies the response based on that Custom header, then it should have
> included the name of that custom header in the Vary response header. If
> it didn't, that would be a bug.
> 
> That being said, IE has lots of issues with Vary, so I wouldn't be
> surprised if servers worked around that by not specifying Vary.
> 
> Related: <http://tools.ietf.org/wg/httpbis/trac/ticket/37>
> 
> > It has been suggested that I should define how this case works in
> > XMLHttpRequest, but I rather just defer to the HTTP for this.
> 
> In theory: yes, in practice it might be useful to call that out in the
> XHR spec as well (if you finish before HTTPbis :-).
> 
> BR, Julian
> 
> 

-- 
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -
- $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -

Received on Tuesday, 10 February 2009 18:03:07 UTC