Subject: Extension headers and caching

From: "Anne van Kesteren" <[email-masked]>
Date: Mon, 09 Feb 2009 12:28:43 +0100

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?

It has been suggested that I should define how this case works in  
XMLHttpRequest, but I rather just defer to the HTTP for this.

Kind regards,

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 09 Feb 2009 12:51:23 +0100

> 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>

> 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

---

From: Eric Lawrence <[email-masked]>
Date: Tue, 10 Feb 2009 17:50:12 +0000

>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: [email-masked] [mailto:[email-masked]] 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

IMHO:

BR, Julian

---

From: Adrian Chadd <[email-masked]>
Date: Wed, 11 Feb 2009 03:02:29 +0900

>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

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Feb 2009 19:08:34 +0100

> Revalidation ensures cache-correctness but entails a performance cost.

As far as I recall it also means that you can't pass content with Vary: 
to an external application, such as an *ics file (IE invokes the 
application with a filename of a temp file that does not exist). This is 
as of IE6, maybe it has been fixed since.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Feb 2009 20:43:52 +0100

> as of IE6, maybe it has been fixed since.

...I just confirmed that with IE7, but it appears to be fixed in IE8!

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 26 Feb 2009 12:29:11 +1100

> surprised if servers worked around that by not specifying Vary.

... and instead making the response otherwise uncacheable (e.g., with  
Cache-Control: private).

That said, my experience is that this is much less common than it used  
to be; people are using Vary more and CC: private (for this purpose  
less).

In any case, the answer to Anne's question is "yes, you should expect  
to get it out of cache, unless the appropriate Vary headers are set,  
or it is otherwise uncacheable." Of course, you can't ever *count* on  
it being in cache in the first place...

Cheers,

--
Mark Nottingham     http://www.mnot.net/