Closed Bug 78551 Opened 24 years ago Closed 23 years ago

url above cached too long

Categories

(Core :: Networking: HTTP, defect, P5)

x86
Linux
defect

Tracking

()

VERIFIED DUPLICATE of bug 98884
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.
Do you have your prefs set to "check once" or "check every time" under "Preferences > Advanced > Cache" ?
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.
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
yeah.. i kind of like this interpretation of the Expires header. what do 4x and IE do?
Target Milestone: --- → mozilla0.9.3
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
Target Milestone: mozilla0.9.3 → mozilla1.0
-> 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.
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.
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.
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!
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
Verified duplicate.
Status: RESOLVED → VERIFIED
QA Contact: tever → junruh
You need to log in before you can comment on or make changes to this bug.