Re: Expires header vs Vary header

Jeffrey Mogul wrote:

>     Yes, of course, but Julian says everything works fine without the
>     Vary. I find it strange that a Vary header would prevent required
>     updates.  But it is still possible, of course. Sorry for not being
>     clear.
>     
> Sorry, I guess I didn't make my own point clear.
> 
> Since RFC 2616 says "the cache MUST update the entry", without
> any language about "but this changes if Vary is used", then what
> Julian complained about seems to be an implementation bug, if
> your interpretation ("Mozilla does not update Expires header when
> receiving a 304 response") was correct.
> 
> If so, I don't think we really need to discuss it on the HTTP-WG
> list.  This should go through Mozilla's bug-reporting process.

Seems so. I just wanted to find out first whether what I am doing is 
supposed to work.

> On the other hand, Mozilla could simply have decided to disable
> caching for any response that carries a Vary header.  This is
> perfectly legal, and is a simple but effective way of ensuring
> that the Vary specification is observed.

Yes, but this is not the case. If the Vary header is present, the 
Expires header on the first 200 response works as expected, and 
furthermore the presence of the ETag causes Mozilla to issue a 
conditional GET. This seems to indicate that caching is supposed to work 
in presence of Vary.

> The problem is that we can only infer whether Mozilla is correctly
> updating its cache entry, so without some other information
> (results of other tests, or reading the source code) we can't
> tell whether this is a case of "Vary prevents required updates"
> or "Vary disables caching".
> 
> I'm sure this has nothing at all to do with Schroedinger's cat.

:-)

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Monday, 8 December 2003 16:50:30 UTC