Closed
Bug 338190
Opened 19 years ago
Closed 16 years ago
Re-requests "Last-Modified" pages without "If-Modified-Since" and duplicates cache entries thereafter
Categories
(Core :: Networking: Cache, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 290032
People
(Reporter: d.voelzke, Unassigned)
Details
Attachments
(5 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414
also affected (tested): Mozilla 1.7.5, Mozilla 1.7.8, Firefox 1.5.0.1 (all Windows XP, 4 different PC)
Mozilla (Firefox) re-requests pages which provided a "Last-Modified" at previous HTTP result without asking for "If-Modified-Since". Therefore, transfer of (large, here: 300KB) files is requested over and over again. We discovered this when running a complex application using xml, xsl and css via an ISDN connection. This application also is intended to run via mobile network modems (9600kbit/sec), so not loading files again is very important.
Fortunately we could reduce the bug to only 3 minimalistic files without any server side active component needed (except a running web server; we used Apache 2.0.54 (with HTTP/1.1) and Apache 1.* (with HTTP/1.0)), although a "fake HTTP server" (php application faking HTTP/1.0) came in handy to track down the bug.
We made Mozilla fetch a file 2 times, the HTTP response of the first fetch returned a "Last-Modified" (but no "Expires", but even with that the bug occurs), the HTTP request of the second fetch didn't ask for "If-Modified-Since" although it was provided and although it was in cache. After the second fetch the cache contained the file 2 times (and after a third fetch 3 times and so on).
Reproducible: Always
Steps to Reproduce:
1. Create three files exactly named and in sub-folders like this:
SomeFolder
|--- cache.xml
|--- XSL
|--- bss.xsl
|--- CSS
|--- bss.css
(SomeFolder containing 1 file "cache.xml" and 2 subfolders: subfolder "XSL" containing file "bss.xsl" and subfolder "CSS" containing file "bss.css").
2. Enter this contents to "cache.xml":
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="XSL/bss.xsl"?>
<Root/>
3. Enter this contents to "XSL/bss.xsl":
<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html"/>
<xsl:template match="/">
<html>
<head>
<title>Cache</title>
<link rel="stylesheet" type="text/css" href="CSS/bss.css"/>
</head>
<body>
Cache
</body>
</html>
</xsl:template>
</xsl:stylesheet>
4. "CSS/bss.css" stays empty, but as verification that it works it might contain:
body { color:blue; }
5. Configure a (local) web server so it can access "cache.xml" with a proper URL
6. Clear the browser cache
7. Enter "http://127.0.0.1/cache.xml" (or whatever proper URL you setup)
8. Enter "about:cache?device=disk" in a second tab and capture output
9. Enter "http://127.0.0.1/cache.xml" again (not using the "reload" button but using the "go" button, or pressing ENTER at the location input field)
10. Enter "about:cache?device=disk" again
Actual Results:
Firefox/Mozilla request "CSS/bss.css" and "XSL/bss.xsl" without "If-Modified-Since" again (and again everytime "cache.xml" is fetched again). Also, both files are added to the cache although they're already in (resulting in duplicates).
Expected Results:
Firefox/Mozilla should request "CSS/bss.css" and "XSL/bss.xsl" with "If-Modified-Since" as provided as "Last-Modified" by the previous result to that files. The web server then can response with "304 Not Modified". Also, if the file is already in cache it shouldn't be added again?
When changing the name of "CSS/bss.css" to e.g. "CSS/xbss.css" the bug doesn't occur: Although only 1 filename was changed both files are fetched as expected with "If-Modified-Since" and aren't duplicated in the cache. Also, then the default expires algorithm comes in and doesn't fetch the 2 "sub-files" at all.
In all tests: browser.cache.check_doc_frequency = 3
On some platform/OS combinations any 3.3-lettered filename causes the misbehaviour (e.g. "CSS/abc.css") on other platform/OS combinations not. The filenames in "Steps to reproduce" cause the bug reliably, any 4.3-lettered filenames never caused the bug (this is our current work-around).
Tested with various Mozilla and Firefox versions (see above), on Windows XP PC and SuSE Linux PC, with Apache 1.*, 2.0.54, a fake web server in php and a fake server in java.
IE doesn't show this bug on neither of the platform/OS/web server combinations.
This might be the same as bug #290032, but since I'm not that deep into the code I'm not sure.
|
||
Comment 1•19 years ago
|
||
Can you provide a HTTP log as described under http://www.mozilla.org/projects/netlib/http/http-debugging.html?
The rar file contains the log as requested (only replaced authorization realm with asterisks).
I also added a http live headers capture (replaced authorization realm and base64 with asterisks). Btw - the described bug occurs in Mozilla/Firefox with and without http live headers installed. We also got same HTTP results with Ethereal.
|
||
Comment 3•19 years ago
|
||
Can you repost this as something other than a "rar" file. Plain text of .zip would be preferred. I don't know of a tool under Linux that I can use to read such a file, and my Windows box is currently busted. Thx!
It's been a while now and the bug is still "unconfirmed".
Do you need anything more?
Can I help you in any way?
Confirming for Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1).
See line 98, when the page was re-fetched; no IMS is sent, and the Expires and Cache-Control: max-age are being ignored.
Maybe an XSL problem (i.e., it's bypassing the cache)?
|
||
Comment 8•18 years ago
|
||
This problem is *still* around!
|
|
||
Comment 9•18 years ago
|
||
Surely this should not still be regarded as UNCONFIRMED?
|
||
Comment 10•17 years ago
|
||
I think if someone else votes for this, that will automatically confirm it.
|
||
Comment 11•16 years ago
|
||
I can reproduce the problem with duplicated cache entries with FF1.5 but not with FF2 and FF3. This part of the bug is probably INVALID or WORKSFORME.
Problem with uncached CSS is the same as in bug #290032, so this part of the bug is a DUPLICATE.
|
|
||
Updated•16 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•