Pages without explicit "Last-Modified" and other cache-validation HTTP headers should not be fetched from the cache if user clicks on a link. Without those headers, there's no way to validate a cache entry. (Note that clicking on a link is not the same as browsing session history with "back" or "forward", which should use the cache. See RFC 2616, Section 13.13) This is similar to Bug #73490, but I would say it should behave the same with or without a '?' in the URL. Basically, no expiration info in the HTTP headers should tell Mozilla not to use the cache, except for session history). This is how Netscape 4/6, IE, and old-cache Mozilla works. I can't tell from RFC 2616 whether this is actually required, but most websites just assume that's how clients work. For example, most shopping carts would not refresh properly with Mozilla 0.9. To reproduce, go to http://www.amazon.com/ and do the following: 1. Add a product to your cart. 2. Click "view cart" (top of page). This URL will be cached. 3. Add a different product to your cart. Note that cart is updated because URL is different from #2. 4. Click "view cart" again. Note that content of cart did not include the item added from #3 because the page is fetched from the cache. I also have a very simple test page at http://www.sily.net/cache-test.jsp
17 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Pages without explicit "Last-Modified" HTTP header → [cache] Pages without explicit "Last-Modified" HTTP header
Summary: [cache] Pages without explicit "Last-Modified" HTTP header → Pages without explicit "Last-Modified" HTTP header shouldn't be cached.
Severity: blocker → critical
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
even if a webserver does not provide explicit cache control headers, we can still use the Date header to send If-modified-since requests, instead of refetching entire documents.
I think If-modified-since is a nice-to-have, but it probably won't help save a re-fetch in this case. If the server doesn't send a Last-Modified, then it probably doesn't know how to handle If-modified-since either. This is because the page is probably dynamically generated. The web application developer probably didn't care or know how to deal with these headers. And in a multi-tiered environment, he can't do anything about it because the application server might not be on the same machine as the web server. And he doesn't have an easy way to ensure that there's no clock skew between those two machines. (The Date header usually comes from the web server, but the If-modified-since header would have to be examined by the application server.)
See bug 46825 (a bug on the old cache) for a discussion of the correct behavior.
I've checked in a patch for bug 75679 that includes the fix for this problem as well. Only if the user has set their cache validation settings to NEVER will we NOT validate/reload pages without an explicit "Last-Modified" header. In all other cases, these pages will be kept up-to-date each time the page is visited via normal browsing (if browsing via history, then the cached page will be shown instead).
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
TEST: This is not the most ideal test, but here is what I did. If found a page that doesn't have a Last-Modified header: http://www.packetgram.com/pktg/ I loaded it twice via the URL field, to see if it would pull from the server. I also checked to verify it did an If-Modified-Since on the second request. I checked every cache mode. It pulls everytime, except for "Never", which seems like what it should do. VERIFIED: Mozilla 0.9 allplats.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.