Cache must obey 'Vary:' HTTP header

RESOLVED FIXED in M17

Status

()

Core
Networking: Cache
P3
minor
RESOLVED FIXED
18 years ago
18 years ago

People

(Reporter: Scott Furman, Assigned: ruslan)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: 1d)

(Reporter)

Description

18 years ago
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
(Reporter)

Updated

18 years ago
Blocks: 14050
Summary: Cache must obey 'Vary:' → Cache must obey 'Vary:' HTTP header
(Reporter)

Comment 1

18 years ago
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.

Comment 2

18 years ago
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)!
(Reporter)

Comment 4

18 years ago
> 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 ?
(Reporter)

Comment 5

18 years ago
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?
(Reporter)

Comment 7

18 years ago
> 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...

Updated

18 years ago
Target Milestone: M15

Comment 9

18 years ago
Assigning fur's cache bugs to Gordon. He can split them up with davidm.

Updated

18 years ago
Target Milestone: M15 → M16

Comment 10

18 years ago
Moving to M17 which is now considered part of beta2.
Target Milestone: M16 → M17

Updated

18 years ago
Keywords: beta2
Whiteboard: 1d

Updated

18 years ago
Keywords: nsbeta2
(Assignee)

Comment 11

18 years ago
-> ruslan
Assignee: gordon → ruslan
Keywords: beta2
(Assignee)

Comment 12

18 years ago
Will not force revalidation if Vary header has been sent.
Status: NEW → RESOLVED
Last Resolved: 18 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?
(Assignee)

Comment 14

18 years ago
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?
(Assignee)

Comment 16

18 years ago
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.