Extension headers and caching

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Extension headers and caching

Anne van Kesteren-2

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

Reply | Threaded
Open this post in threaded view
|

Re: Extension headers and caching

Julian Reschke

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


Reply | Threaded
Open this post in threaded view
|

RE: Extension headers and caching

Eric Lawrence-4
>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: [hidden email] [mailto:[hidden email]] 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


Reply | Threaded
Open this post in threaded view
|

Re: Extension headers and caching

Adrian Chadd

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

Reply | Threaded
Open this post in threaded view
|

Re: Extension headers and caching

Julian Reschke
In reply to this post by Eric Lawrence-4

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

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

Reply | Threaded
Open this post in threaded view
|

Re: Extension headers and caching

Julian Reschke

Julian Reschke wrote:
> 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.

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

BR, Julian




Reply | Threaded
Open this post in threaded view
|

Re: Extension headers and caching

Mark Nottingham-2
In reply to this post by Julian Reschke

On 09/02/2009, at 10:51 PM, Julian Reschke wrote:

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


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