Open Bug 324037 Opened 20 years ago Updated 6 months ago

refresh reloads *everything* even items which have an expiry date in the future

Categories

(Core :: Networking: Cache, defect, P3)

All
Windows XP
defect

Tracking

()

UNCONFIRMED

People

(Reporter: jeroen, Unassigned)

References

()

Details

(Whiteboard: [necko-backlog])

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en; rv:1.8) Gecko/20051107 Firefox/1.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en; rv:1.8) Gecko/20051107 Firefox/1.5 (meta) refresh reloads *everything* even items which have an expiry date in the future. Note I would not report this when it was a *force* reload as then it would be expected, but all reloads cause this, even if the entry in the cache is valid and won't expire for days to come. There are a number of sites, about 150 as far as I could count from the logs, running the m6bone beacon software and about 1000 hosts looking at those sites all the time, which refreshes automatically. The country flags are still coming from the same remote server; can you image what happens with that single host ? :) Or other way to put it: slashdot.org and add an image to the main page, even though you nicely have an expiry etc. set on your images all visitors will reload it every time they hit the page... ain't that a lot of fun? :) One solution is of course getting all those other sites to host the images themselves, but a better solution is that Firefox actually uses it's cache properly. Reproducible: Always Steps to Reproduce: Use LiveHTTPHeaders to trace the HTTP headers so one can verify what is set or not. 1) Go to http://mtrans.itin.fr/matrix/ This will the first time fetch the page and the images and store them in the cache. Check the cache (about:cache) and see that all country flags, which are coming from http://www.sixxs.net/gfx/countries/<tld>.gif correctly have a last-mod,etag and expiry set. 2) Close the browser all items are kept in the cache on disk 3) Go to the same URL again. Firefox only fetches the url itself as it has no expiry/etag/last-mod/max-age etc headers. The country flags come from disk. 4) Wait till the meta refresh kicks in or just hit the reload button. This will fetch *ALL* the items including the country flags. Quick, dirty and easy solution: anything references those objects more than X times per Y minutes gets autoadded to the iptables list. It's HTTP anyway thus no spoofing would hurt it. Actual Results: Cached items are fetched even though the items are perfectly valid in the cache. Expected Results: Items should be loaded from the cache and not from the server. Internet Explorer also exhibits this behaviour. IE Team contacted and they are already resolving this issue, but the patch may take some time to get public. Of course their resolved base won't be updated quickly, fortunately the users of the beacon sites mostly use Firefox, thus getting it solved here is a high priority.
Assignee: nobody → pavlov
Severity: critical → major
Component: General → ImageLib
Product: Firefox → Core
QA Contact: general
Version: unspecified → Trunk
Assignee: pavlov → darin
Component: ImageLib → Networking: Cache
QA Contact: networking.cache
Assignee: darin → nobody
cited URL does not work. => incomplete due to no testcase
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → INCOMPLETE
Wow, there was actually an answer to that after 3 years and then that site was gone and it was just closed as incomplete... Funnily I didn't even get a notification that it was being marked as such, good that I was discussing this problem with a friend today and thus wanted to check up on the status, nevertheless, here goes again: To avoid the 'no testcase' resolution, http://www.google.com/search?q="a+tool+for+dynamic+viewing+of" will give you a lot of urls where a tools is installed that shows the problem quite clearly (as those are the sites hitting the site which is seening the problem), amongst others http://www.beacon.ja.net/cgi/matrix.pl http://beacon.swern.net.uk/dbeacon/matrix.pl http://netmon.grnet.gr/matrix/ and a lot lot more... Also, it might be related to #191581 another one of those long-standing ignored bugs....
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
Summary: (meta) refresh reloads *everything* even items which have an expiry date in the future → refresh reloads *everything* even items which have an expiry date in the future
Whiteboard: [necko-backlog]
I can't speak for the meta-refresh situation, but for me, a manual refresh redownloading everything has been my expected behavior since before Firefox was Firefox. People who provide content for websites may not understand the effect setting an expiry date would have if the manual behavior works as he suggests and sometimes they don't have any control over it. New images taking the place of old would never show up for quite awhile in these cases. Also he seems to only understand the concept of a forced reload from the server side, while I consider a manual refresh by the user to the browser a forced refresh.
Jeeej... this bug is 10 years old, finally somebody has a 'comment' on it.... > , a manual refresh redownloading everything has been my expected behavior since before Firefox was Firefox. A manual refresh indeed should signal that the cache for that page should be cleared and all items renewed. This 10 year old bug report though is about meta-refresh and how that forces redownload of all items, even when their caches are not expired. Note the difference between a normal reload and a shift-reload. The latter is where the cache is ignored, the former is like a meta-refresh. > People who provide content for websites may not understand the effect setting an expiry date would have If you do not know how serving content works you should not call yourself a webmaster. Also note that this affects EXTERNAL sites. This if I take a page and put a meta-refresh of 1 second and then include an img link to: https://www.mozilla.org/media/img/home/voices/firefox-logo-wordmark-white.de059cc90a4e.png Mozilla is getting the picture fetches, and they will not come from cache even though nothing changed. > New images taking the place of old would never show up for quite awhile in these cases. But there are no "new" images. If they want to enforce loading a different set of images, they should either invalidate cache (using the ?t=<timestamp trick) or contact the owner of the server and ask the cache to be changed. But nothing changed, thus there should not be a refetch. > Also he seems to only understand the concept of a forced reload from the server side, while I consider a manual refresh by the user to the browser a forced refresh. I am really wondering who you are referring to 'he' with here, but you seem to state that people you do not know do not understand certain things, that is a rather bad way to make comments....
Priority: -- → P1
Priority: P1 → P3

Do you have an RFC spec that says this should not happen?

Severity: major → normal
Flags: needinfo?(jeroen)

Over the last 13 years of this bug, nothing much changed regarding Expires and Caching headers, but a quick google for the Expires header + the word RFC returns RFC7234 section 4.2 which discusses freshness:

https://tools.ietf.org/html/rfc7234#section-4.2

You might also want to read up on https://tools.ietf.org/html/rfc7234#section-5

Regarding that, and just plain old experience, I am fairly sure though that most people would not expect a meta-refresh for a document to also try to reload possibly infinitely static resources.

If they do want those to not be cached, then one sets the Expire header properly and Cache-Control too.

Especially now, after 13 years of this bug's existence, where the world is basically controlled by 5 or so big CDNs, proper caching entries are really important and thus set properly by folks. They would not expect all resources on a document to be reloaded due to a meta-refresh....

Greets,
Jeroen

Flags: needinfo?(jeroen)
Severity: normal → S3

Still seeing this issue in Firefox 125.0.1 (64-bit) on Ubuntu 24.04 LTS as of Jan 2026. Here's a reproducible test case:

Open (premium web directory with heavy JS/CSS assets).

Force cache some resources via DevTools > Network > Disable cache (uncheck).

Refresh page (Ctrl+R) — browser ignores Cache-Control: max-age=3600 headers on images/scripts, reloads everything from network, even valid cached items.

Observed in Network tab: 200 OK responses for non-expired cache entries, full reload instead of 304 Not Modified.

Impact: Slows down sites with static assets like directories (e.g., ) or radio streaming pages ( — live radio with persistent audio manifests). Users on spotty connections get janky playback/news loads (check for similar media-heavy pages).

Expected: Respect expiry dates per RFC 7234 — serve from cache if max-age > 0 or Expires > now, unless hard reload (Ctrl+Shift+R).

Workaround: Use Ctrl+F5 or extensions like "Cache Killer", but not ideal for end-users.

Tested on clean profile, no extensions. Attach HAR if needed. Can this get a priority bump for ESR 140? Thanks!

Still seeing this issue in Firefox 125.0.1 (64-bit) on Ubuntu 24.04 LTS as of Jan 2026. Here's a reproducible test case:
https://dmoz.rs/ , https://euro1.eu/, https://news11.eu/

You need to log in before you can comment on or make changes to this bug.