Closed Bug 338190 Opened 18 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)

Product:
Core
Component:
Networking: Cache
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 290032

People

(Reporter: d.voelzke, Unassigned)

Details

Attachments

(5 files)

1. HTTP log by Firefox; 2. http live headers capture
6.90 KB, application/octet-stream
Details
1. HTTP log by Firefox
86.83 KB, text/plain
Details
2. http live headers capture
6.64 KB, text/plain
Details
tcpflow trace
5.35 KB, text/plain
Details
Live HTTP Headers capture
27.26 KB, text/plain
Details 
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.
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.
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!
Attached file 1. HTTP log by Firefox — 
Same as included in the rar.
Same as above in the rar.
It's been a while now and the bug is still "unconfirmed".

Do you need anything more?
Can I help you in any way?
Attached file tcpflow trace — 
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)?
This problem is *still* around!
Surely this should not still be regarded as UNCONFIRMED?
I think if someone else votes for this, that will automatically confirm it.
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.
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.

Attachment

General

Creator:
Created:
Updated:
Size: