Closed
Bug 78551
Opened 24 years ago
Closed 23 years ago
url above cached too long
Categories
(Core :: Networking: HTTP, defect, P5)
Tracking
()
mozilla1.0.1
People
(Reporter: a-huntwork, Assigned: darin.moz)
References
()
Details
When I visit www.cnn.com, I often get what looks to me like an old version of
the page, i.e., the same version I got a few hours earlier. When I reload, i
often get a new version. Here's my current cache entry, just after i visited
the page but don't reload.
Key: http://www.cnn.com/
Data size: 226155 Bytes
Fetch count: 15
Last Modified: Wed 02 May 2001 02:55:41 PM CDT
Expires: Wed 02 May 2001 02:45:39 PM CDT
Here it is right after i hit reload.
Key: http://www.cnn.com/
Data size: 284444 Bytes
Fetch count: 17
Last Modified: Wed 02 May 2001 03:08:27 PM CDT
Expires: Wed 02 May 2001 03:08:26 PM CDT
I'm pretty sure it's inappropriately caching, but maybe I'm wrong. The expires
thing seem spretty suspect to me. The last modified time in both cases is the
time I viewed it, regardless of whether I hit reload, but expires is the time I
hit reload.
Comment 1•24 years ago
|
||
Do you have your prefs set to "check once" or "check every time" under
"Preferences > Advanced > Cache" ?
Reporter | ||
Comment 2•24 years ago
|
||
it was once per session. does that make this bug invalid? I'm not sure. I
would expect that regardless of the cache settings, an expired page would be
reloaded. I think the about:cache entries below indicate that this is not
happening. btw, build 200105108.
I'm going to run with check every time for a while. presumably that'll fix this
problem.
With "once per session" expired content will be checked only once, and new
content will never be checked, even after it expires, during that session.
Darin, is my understanding correct?
Assignee: gordon → darin
Component: Networking: Cache → Networking: HTTP
If the server explicitly sends an "Expires" header, why not honor it? It seems
like the Right Thing to do. I think the "once per session", "every page", or
"never" rules are applicable only when the server doesn't send an "Expires" header.
BTW, www.cnn.com is setting the "Expires" header at one minute _after_ the
"Last-modified" header. It looks like the cache isn't recording this informatin
correctly.
Assignee | ||
Comment 6•23 years ago
|
||
yeah.. i kind of like this interpretation of the Expires header. what do 4x
and IE do?
Target Milestone: --- → mozilla0.9.3
Assignee | ||
Comment 7•23 years ago
|
||
the default cache validation pref is now "automatically / when appropriate"
so this bug definitely is less serious since the Expires header would be
honored in this case.
Severity: normal → minor
Priority: -- → P5
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.3 → mozilla1.0
Assignee | ||
Comment 8•23 years ago
|
||
-> not critical for mozilla 1.0
Target Milestone: mozilla1.0 → mozilla1.0.1
Darin, is there anything here we want to fix or should we just close this bug?
The validation prefs are for the user, so I don't agree that we should ignore
the user's wishes by always using the expires header from the server, if present.
Assignee | ||
Comment 10•23 years ago
|
||
gordon: i'm not sure about cache validation prefs, etc... but in loading
www.cnn.com and inspecting about:cache, i did observe a somewhat strange
expiration time similar to what the reporter described. when i pressed reload,
the expiration time seemed to be what i expected it to be -> one minute in the
future. so, i think there is a bug here... i just don't know for sure what it
could be.
Comment 11•23 years ago
|
||
I've run into this situation before many times during web development, to my
great chagrin. I would edit my Visual Basic program, and rerun it expecting a
certain result, but when I reloaded the page, the change wouldn't be there, so
I'd go back and check and recheck my work, when in fact if I loaded it in MSIE
or Netscape 4.x it would have shown up right away. This is even though I always
have my cache prefs set to check "Every time I view the page." I ran into this
problem just yesterday, in fact, using a 1/15 build. If I completely exit
Mozilla and restart, it'll work. If I check the about:cache entry, it is set to
expire immediately.
Assignee | ||
Comment 12•23 years ago
|
||
greg: can you describe the HTTP headers used when serving up your document? or
perhaps any other information pertaining to your network setup... eg. are you
connecting via a HTTP proxy? can you capture network traffic while the problem
is happening? or even better can you demonstrate this bug with the the
following environment variables set:
NSPR_LOG_MODULES nsHttp:5
NSPR_LOG_FILE c:\http.log
and then attach the file "http.log" to this bug report? if so, it would be a
tremendous help. thx!
Assignee | ||
Comment 13•23 years ago
|
||
actually, the original was fixed a while ago. there was a problem w/ the
handling of META HTTP-EQUIV headers that only showed up on 304 responses. in
the case of www.cnn.com, the expiration information is exclusively in META tags,
so on reload we'd end up losing the META tag info and therefore end up with a
zero freshness lifetime.
marking duplicate of bug 98884
greg: you should file a new bug for the problem you are seeing. please include
as much information as you can. thx!
*** This bug has been marked as a duplicate of 98884 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•