Closed Bug 21561 Opened 25 years ago Closed 24 years ago

Cache must obey 'Vary:' HTTP header

Categories

(Core :: Networking: Cache, defect, P3)

Product:
Core
Component:
Networking: Cache
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: fur, Assigned: ruslan)

References

Details

(Whiteboard: 1d) 

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
Blocks: 14050
Summary: Cache must obey 'Vary:' → Cache must obey 'Vary:' HTTP header
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...
Target Milestone: M15
Assigning fur's cache bugs to Gordon. He can split them up with davidm.
Target Milestone: M15 → M16
Moving to M17 which is now considered part of beta2.
Target Milestone: M16 → M17
Keywords: beta2
Whiteboard: 1d
Keywords: nsbeta2
-> ruslan
Assignee: gordon → ruslan
Keywords: beta2
Will not force revalidation if Vary header has been sent.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
What exactly is the fix you made?

Going back to fur@netscape.com'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.
You need to log in before you can comment on or make changes to this bug.