W3C home > Mailing lists > Public > www-talk@w3.org > November to December 2004

HTTP Vary: and conditional requests

From: Phil Endecott <spam_from_www_talk@chezphil.org>
Date: Fri, 12 Nov 2004 12:55:08 +0000
Message-ID: <4194B2AC.8010100@chezphil.org>
To: www-talk@w3.org

Dear HTTP experts,

I recently filed a Mozilla bug report about odd behaviour when the Vary: 
header and if-modified-since requests are combined.  The answer was "our 
behaviour is per RFC2616 (HTTP)" and that seems to be true, yet it 
doesn't do what I expected.  Here is the scenario:

You have never visited my site before so have nothing cached and no cookies.

You visit page P which returns
   Last-modified: long-ago
   Vary: Cookie
along with its content, which you store in your browser cache.

You navigate to some other page on the same site which sends you a cookie.

You visit page P again.  Since your cached copy of P includes a vary: 
Cookie header, and you now have a cookie that you didn't have before, 
you can't use your cached copy.

What Mozilla does, and this does seem to agree with RFC2616 section 
13.6, is that it sends a conditional if-modified-since request for the 
page.  My server replies with a 304 status since the version of the page 
for visitors with the cookie really is the same now as it was long ago. 
  So the user sees the wrong thing.


The bit of RFC2616 in question is this paragraph from section 13.6:

    If the selecting request header fields for the cached entry do not
    match the selecting request header fields of the new request, then
    the cache MUST NOT use a cached entry to satisfy the request unless
    it first relays the new request to the origin server in a conditional
    request and the server responds with 304 (Not Modified), including an
    entity tag or Content-Location that indicates the entity to be used.

I would argue that it should not send a conditional request.  The Vary: 
cookie header and the fact that the cookie has changed indicates that a 
different entity is being requested from the one that is cached.

The same thing will occur with multilingual pages and accept-language. 
If I fetch a page with one accept-language setting, then fetch it again 
with this header changed, it will send an if-modified-since request, get 
a 304 response, and display the page in the wrong language.

(I am not using Etags here; I believe that most of the issues go away if 
you do.)

Can anyone shed any light on this?

Regards,

Phil Endecott.


p.s. the Mozilla bug is at 
https://bugzilla.mozilla.org/show_bug.cgi?id=269303
Received on Friday, 12 November 2004 14:04:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:28 GMT