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)
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:
Comment 1•22 years ago
|
||
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
Reporter | ||
Comment 2•22 years ago
|
||
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.
Comment 4•22 years ago
|
||
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.
Reporter | ||
Comment 5•22 years ago
|
||
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.
Comment 6•19 years ago
|
||
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/
Reporter | ||
Comment 7•19 years ago
|
||
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
Reporter | ||
Comment 8•18 years ago
|
||
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.
Description
•