The cache needs to notice if a server sends back a 'Vary:' header in its HTTP response. Probably, the easiest thing to do is to just treat such a response as non-cachable. See this link for more info on the Vary header: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44
An alternative is to add the values of the Accept* headers to the secondary cache key, e.g. so that if a URL is fetched with two different Accept-Language headers, the cache stores each in a separate cache entry.
Bulk move of all Cache (to be deleted component) bugs to new Networking: Cache component.
It would be nice if you actually stored the Vary header (along with what headers you sent), although that might be difficult. At the least, you could ignore "Vary: User-Agent" (which is important for proxies)!
> It would be nice if you actually stored the Vary header (along with > what headers you sent), although that might be difficult. It is already the case that the Vary header is stored in the cache, along with all other end-to-end HTTP response headers. However, I don't think it's necessary to do so in order to fix this bug. (See below.) > At the least, you could ignore "Vary: User-Agent" (which is important for > proxies)! Excellent point ! But, going back to my earlier comment, I think the right thing to do instead of ignoring all responses that contain the Vary header, is to fold in the Accept* headers into the secondary cache key, i.e. so that if a URL is fetched with two different Accept-Language headers, the cache stores each in a separate cache entry. Doing so would eliminate the requirement that the caching code deal explicitly with the Vary header and ensures that the cache will do the right thing with pre-1.1 HTTP servers. Incidentally, the only header I could think of that might vary over the life of the cache was Accept-Language. Are there any others ?
Oh yeah, Accept-Charset might change, based on the "Character Set" menu selection.
Would that mean that if a user changed language preferences, every document would have to be re-retrieved from the server, even if it didn't have a Vary header?
> Would that mean that if a user changed language preferences, every document > would have to be re-retrieved from the server, even if it didn't have a Vary > header? Yes, but my impression was that most people did not fool around with their language settings after initial browser setup. Is that not a correct assumption ?
Yeah, probably. I guess I don't fiddle with mine too often...
Assigning fur's cache bugs to Gordon. He can split them up with davidm.
Moving to M17 which is now considered part of beta2.
Will not force revalidation if Vary header has been sent.
What exactly is the fix you made? Going back to firstname.lastname@example.org's comment of 1999-12-18 08:25, would it make any sense to fold headers into the secondary cache key only when they're given in a Vary header?
the present fix always treats the response as one that needs revalidation when Vary header was present, for now. If Vary: * we probably don't need to cache it at all.
Does "always needs revalidation" mean that it always needs to be fully reloaded when there is a need to go back to the server (as defined by the cache preference). Or does it mean that the cache preference will be ignored and you will always go back and do a HEAD from the server? Or that the cache preference will be ignored and you will always go back and do a complete GET from the server?
it will ignore the cache preference and will always go back to the server to see if the content is valid
I have filed a bug requesting correct Vary support as bug 37609, and I explain there why I think it is important.