Closed Bug 207069 Opened 22 years ago Closed 18 years ago

Sometimes a graphic used multiple times in a page is refetched for each occurance

Categories

(Core :: Networking: Cache, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 197824

People

(Reporter: jve, Assigned: gordon)

References

()

Details

User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030515 Mozilla Firebird/0.6 This is from a site administrators point of view... We have had visitors with a Gecko User Agent whose clients just go nuts refetching images. Only a few Gecko visitors have this problem, so it must be some preference setting that is causing this. Here's a sorted list of URLs - count / URL - from one recent visitor: 1 /dl/games/chrome/chrome_teaser.mpg.html 1 /dl/games/chrome/chromepix6.zip.html 1 /dl/games/chrome/chromepix7.zip.html ... 114 skipped ... 1 /games/wolfensteinet/ 2 /games/U/ 2 /games/apacheairassault/ 3 / 3 /dl/games/apacheairassault/apachepix2.zip.html 126 /i/on.gif 128 /i/lit.gif 128 /style/all.css 3281 /i/off.gif 4269 /i/bar-gray.gif 4286 /i/1.gif This user viewed 128 pages. Each page has one reference to on.gif, lit.gif, and all.css. Each page has about 25 uses of off.gif and over 30 uses each of bar-gray.gif and 1.gif. With each usage within a page, the graphic was fetched anew. These requests were logged with a status of 200, not 304, so they were unconditional GETs, not "if modified since" GETs. If this is from a user choosing the "Compare the page in the cache to the page on the network every time I view the page" option, only the page should get checked and possibly refetched - not the static elements, right? If this is from a user zeroing out both the disk cache and memory cache (!!) then shouldn't there still be some per-page cache to cache repeated elements while building the page? This issue is not new with 1.4b - we've seen it for many months, but this user's total requests really stood out in our statistics, so now it's time to report this to see if this situation can get handled in a more server-friendly manner. Reproducible: Didn't try Steps to Reproduce:
which Mozilla build are this people using ? >user zeroing out both the disk cache and memory cache This is unsupported and could cause something like this
The user agent for the recent requests is the one in the "Build Identifier", above, but this kind of thing has happened for earlier builds as well. Maybe a minimum disk cache size should be required to make sure this kind of issue can never arise. Even 1 MB is better than nothing.
I tested mozilla 1.4 on a page I constructed with multiple uses of an image on a page, with "Compare every time" set for my cache preference. I see only a single GET for the image, and subsequent page visits issue a 304 rather than 200. Therefore, this problem is dependent on more than just that preference setting. If the users cache capacities were set to zero (both disk and memory), it could have this effect. That is not a recommended/supported configuration, and in fact the UI for changing the memory cache capacity was removed from the preference panel. The simple fact is: with no caches, the browser doesn't work quite right. One solution we may consider is interpreting a memory cache capacity of zero as 'determine the capacity dynamically' just like a negative capacity value. We would then rely on the browser.cache.memory.enable pref to turn on/off the memory cache for testing purposes.
you don't need to zero memory cache to cause this, just disk cache. #197824 I tested on www.3dgamers.com with 1.2.1-9 and a recent firebird. With disk cache disabled and memory cache set to 131071, 1.2.1 cached the little images, firebird did not.
Another example with a more recent, non-Firebird, User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030613 This appears to be 1.5 alpha, so the problem still exists in the newest code. Here's the sorted list of URLs with the count for each: 1 / 1 /games/ 1 /news/class/ 1 /news/class/movie/?offset=150 1 /news/class/movie/?offset=200 1 /news/class/movie/?offset=250 1 /news/class/movie/?offset=300 1 /news/class/movie/?offset=350 1 /news/more/1001026134/ 1 /screenshots/games/serioussam2/ 2 /games/serioussam/ 2 /news/class/movie/?offset=100 2 /news/class/movie/?offset=400 2 /news/class/movie/?offset=50 2 /news/game/serioussam/ 2 /news/more/938073540/ 2 /search/?keywords=serious+sam 3 /games/S/ 4 /news/class/movie/ 5 /news/game/serioussam2/ 6 /games/serioussam2/ 7 /news/more/1007074219/ 48 /i/on.gif 48 /style/all.css 58 /i/lit.gif 1317 /i/off.gif 1721 /i/1.gif 1724 /i/bar-gray.gif Same pattern/distribution as before.
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
The problem is still happening. After a site redesign, the most commonly referenced image is now "space.gif", with a few dozen references within any given page. During a recent 24 hour period, these individual hosts had the most GETs (with status 200) for that file: 1553 adsl-81-242-93.shv.bellsouth.net 1075 22.3-246-81.adsl-fix.skynet.be 362 c-24-18-240-159.hsd1.wa.comcast.net 247 ip68-0-204-99.ri.ri.cox.net 83 adsl-165-51.37-151.net24.it Here are the counts of the User Agent strings for those hosts: 1553 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 1075 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 362 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7 247 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7 83 Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv:1.7.12) Gecko/20050919 Firefox/1.0.7 As you can see, they are all various recent versions of Firefox. About 25% of our visitors use Firefox, but only a few of them exhibit this problem. It's as if there's no memory cache and each image has to be fetched anew on each reference in the page. Mind you - this is from the POV of a server, and trying to contact these users to enquire about their usage is impossible (or at least very, very difficult). As noted by Shawn, above, related bug is bug 197824
Since I am no longer affiliated with the domain in my "Reported" email address, I am resolving this bug as a duplicate of bug 197824 (which itself was resolved as EXPIRED on 2005-10-13).
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.