Closed
Bug 21561
Opened 25 years ago
Closed 25 years ago
Cache must obey 'Vary:' HTTP header
Categories
(Core :: Networking: Cache, defect, P3)
Core
Networking: Cache
Tracking
()
RESOLVED
FIXED
M17
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
|
Reporter | |
Updated•25 years ago
|
Blocks: 14050
Summary: Cache must obey 'Vary:' → Cache must obey 'Vary:' HTTP header
|
|
Reporter | |
Comment 1•25 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.
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•25 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•25 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•25 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•25 years ago
|
Target Milestone: M15
|
|
||
Comment 9•25 years ago
|
||
Assigning fur's cache bugs to Gordon. He can split them up with davidm.
|
|
||
Comment 10•25 years ago
|
||
Moving to M17 which is now considered part of beta2.
Target Milestone: M16 → M17
|
Assignee | |
Comment 12•25 years ago
|
||
Will not force revalidation if Vary header has been sent.
Status: NEW → RESOLVED
Closed: 25 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•25 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•25 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.
| Comment hidden (collapsed) |
You need to log in
before you can comment on or make changes to this bug.
Description
•