Firefox redownloads CSS styles every time I visit this site (i.e. cache is malfunctioning) - optimize the 'freshness' calculation to prevent 'very short freshness' issue

RESOLVED WONTFIX

Status

()

--
enhancement
RESOLVED WONTFIX
13 years ago
3 years ago

People

(Reporter: aros, Assigned: alfredkayser)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

6.42 KB, application/octet-stream
Details
(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050921 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050921 Firefox/1.6a1



Reproducible: Always

Steps to Reproduce:
1. Open http://slashdot.org in the trunk version of firefox
2. FF will load CSS style files from images.slashdot.org
3. Close FF
4. Again open http://slashdot.org 
Actual Results:  
FF will load CSS styles files from images.slashdot.org though the CSS style
files must be cached

Expected Results:  
FF uses its cache instead of reloading CSS style files.

Comment 1

13 years ago
Could you create a log as described at
http://www.mozilla.org/projects/netlib/http/http-debugging.html and attach it to
this bug?

possibly bug 290032
(Reporter)

Comment 2

13 years ago
Actually I understood what caused this FF behaviour:

I opened about:cache?device=disk and I saw this (other slashdot CSS files have
the same entries):

           Key: http://images.slashdot.org/print.css
     Data size: 533 bytes
   Fetch count: 4
 Last modified: 2005-10-01 13:37:08
       Expires: 2005-10-01 18:50:04

So CSS style files are redownloaded every next day. 
BUT:

telnet images.slashdot.org 80
Trying 66.35.250.55...
Connected to images.slashdot.org.
Escape character is '^]'.
GET /print.css HTTP/1.1
Site: images.slashdot.org

HTTP/1.1 200 OK
Date: Sat, 01 Oct 2005 10:02:38 GMT
Server: Boa/0.94.14rc17
Accept-Ranges: bytes
Connection: Keep-Alive
Keep-Alive: timeout=10, max=1000
Content-Length: 1441
Last-Modified: Thu, 29 Sep 2005 03:27:03 GMT
Content-Type: text/css

No expiration date is set in HTTP headers. That makes me wonder why FF decides
that CSS files "Expires: 2005-10-01 18:50:04".

Anyway I'm attaching the log file you have requested.
(Reporter)

Comment 3

13 years ago
Created attachment 198118 [details]
Firefox NSPR_LOG

This is the log file I got by
$ export NSPR_LOG_MODULES=nsHttp:5,nsSocketTransport:5,nsHostResolver:5
$ export NSPR_LOG_FILE=/tmp/log.txt
$ firefox

Comment 4

13 years ago
If no expires is specified, a date is calculated based on the last modified of
the document, which I believe results in the document expiring about 1/10th of
it's age into the future (so if the document was last modified 10 hours ago,
Firefox would make it expire in 1 hour - Darin will correct me here). The
comment here shows the logic for calculating the "freshness lifetime":

http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHttpResponseHead.cpp#266

Comment 5

13 years ago
Yeah, this is working as designed.  See RFC 2616 where the Last-modified based
expiration time calculation is prescribed.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
(Assignee)

Comment 6

13 years ago
RFC2616 says:
  "Also, if the response does have a Last-Modified time, the heuristic
   expiration value SHOULD be no more than some fraction of the interval
   since that time. A typical setting of this fraction might be 10%."
So, it 'might be' 10%, but possible more, but not more than the 'interval since
that time', so may be instead of just doing 10%, do 100% for the very short
intervals so prevent very very short freshness settings?

define age = 'interval since that time'
if (age < 1 day) freshness = age              // 100% of age
else if (age < 10 days) freshness = 1 day     // between 10 and 100%
else freshness = age/10                       // 10% age

the 'SHOULD be no more' even allows to have a minimum freshness threshold:
   if freshness < 1 hour freshness = 1 hour     
to prevent very short freshness 

Note, that this only applies to the
     // Fallback on heuristic using last modified header...
at
http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHttpResponseHead.cpp#300

Comment 7

13 years ago
Alfred: Yeah, I have often thought about improving our Last-modified heuristic.
 Something progressive probably does make the most sense.
(Reporter)

Comment 8

13 years ago
Darin: From you point of view I can't understand whether the accident I have
reported is a bug or a feature request. May I hope someone will work on this in
order to improve caching policy? Maybe it's worth implementing simple rules for
caching different type of documents? I.e. don't cache HTML or alike documents
and use cache as much as possible for the types other than HTML.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
(Assignee)

Comment 9

13 years ago
To clarify a bit, the plan is to comply with the RFC standards.
According to Darin the cache is working as it should (according to the standards). 

What seems to happen is that some files (such as css's) are so shortlived that
they disappear from the cache very quickly. What I propose to do, is to
fine-optimise the 'freshness' calculation within the bounds of the specification
to prevent this 'very short freshness' a bit.

Comment 10

13 years ago
confirming, and reassigning to alfred ;)
Assignee: darin → alfredkayser
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

13 years ago
Blocks: 290032

Updated

13 years ago
Blocks: 321251
(In reply to comment #0)
> 2. FF will load CSS style files from images.slashdot.org
> 3. Close FF
> 4. Again open http://slashdot.org 

What is you cache option setting?
If "When the page is out of date"(browser.cache.check_doc_frequency=3, default), I think problem is simply that "Heuristic Expiration" is larger than one user is convinced, and "improving" by Darin Fisher in Comment #7 may work.
But if "Once per session"(browser.cache.check_doc_frequency=0), problem of Bug 221036 can also be involved because your scenario has restart step of FF.

Comment 12

13 years ago
No, this is actually the opposite case of bug 221036:

This issue is about extending the heuristic expiration time in specific cases (e.g. as described in comment #6) in order to keep files without an explicit expiration time longer in the cache than we do now. Bug 221036 is a request to not use (or revalidate) a cached resource under the same circumstances when it is first accessed in a session.

Setting severity to enhancement (this is definitely not major).
Severity: major → enhancement
(Reporter)

Comment 13

13 years ago
(In reply to comment #11)

> What is you cache option setting?

I have browser.cache.check_doc_frequency=3 in my settings. BTW, as for #1 - closing FF is not necessary at all. Just reopening ./ in around an hour makes FF redownload all CSS and JS files.

Updated

8 years ago
Summary: Firefox redownloads CSS styles every time I visit this site (i.e. cache is malfunctioning) → Firefox redownloads CSS styles every time I visit this site (i.e. cache is malfunctioning) - optimize the 'freshness' calculation to prevent 'very short freshness' issue
not going to mess with the heuristic over one site when explicit options are available to it.
Status: NEW → RESOLVED
Last Resolved: 13 years ago3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.