User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030827 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030827 * When cache "once per session" or "when the page is out of date" is selected and the Web Server does not send the "Expires" header, Mozilla automatically sets an expiration date, so on the next session the page is fetched from the cache and it is not compared with the server one. When the web master updates the page, for some days the page is fetched from cache with obvious problems. Reproducible: Always Steps to Reproduce: 1. Load a page with cache set to "once per session" 2. Close the browser 3. Reopen the browser and reload the same page Actual Results: When you load the page after restart the browser, the page is not fetched from the web server. If you do "about:cache", you see the Expiration date set some days after the load date. Expected Results: Don't store the Expiration date and compare the page with the web server one 1 time at session (with both "once per session" and "when the page is out of date" if the web server does not send "Expires" header).

Possibly related to bug#204860 and bug#203271; Though both Expires and Last-Modified not working for me..

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/

This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.

I re-check, the bugs persist also in latest version: - Mozilla suite 1.7.10 - Firefox 1.0.6 I'll try to check in the source code in order to fix the bug... If someone know which are the source files involved in cache control, please contact me!

What does session mean in this context? In some contexts it means the session layer http://en.wikipedia.org/wiki/OSI_model In others it means from the point that the browser process gets started to the time it is killed. In reference to the cache I originally thought the latter, but if that is true it is becoming less and less relevant to the user experience and the role the cache plays in it.

Luca Bonissi(bug opener), can you attach HTTP Header log? (Sorry but I don't know site who doesn't return "Expires"). See http://livehttpheaders.mozdev.org/index.html and install extention of LiveHTTPHeaders. 1. Load a page with cache set to "once per session" (1-1) Clear cache (to make about:cache display simple) (1-2) Start LiveHTTPHeaders logging (1-3) Shift+Reload (request with no-cache) (1-4) Reload (request with If-Modified-Since, probably) (1-5) about:cache (both memory cache and disk cache) 2. Close the browser 3. Reopen the browser (3-1) Start LiveHTTPHeaders logging (3-2) Load the same page (usually link click or open from bookmark) (3-3) about:cache (both memory cache and disk cache) When attach log file thru link of "Create a New Attachment", please specify "text/plain", for ease of viewing by browser. And, if possible, let us know URI where problem occured or occurs, or attach the HTML on which problem occured, or attach simple/minimized test case.

the method at http://www.mozilla.org/projects/netlib/http/http-debugging.html may be more useful than a livehttpheaders log, and doesn't require installing an extension...

For the test I used Mozilla Suite 1.7.5, but the problem is for any Mozilla version. > 1. Load a page with cache set to "once per session" > (1-1) Clear cache (to make about:cache display simple) > (1-2) Start LiveHTTPHeaders logging > (1-3) Shift+Reload (request with no-cache) > (1-4) Reload (request with If-Modified-Since, probably) > (1-5) about:cache (both memory cache and disk cache) log1.txt and disk1.html are the attachments for this test. The log lines in the web server are: 10.0.0.76 - - [24/Feb/2006:00:53:05 +0100] "GET /test.html HTTP/1.1" 200 753 "-" "Mozilla/5.0 (X11; U; Linux i686; it-IT; rv:1.7.5) Gecko/20041221" 10.0.0.76 - - [24/Feb/2006:00:53:09 +0100] "GET /test.html HTTP/1.1" 200 753 "-" "Mozilla/5.0 (X11; U; Linux i686; it-IT; rv:1.7.5) Gecko/20041221" 10.0.0.76 - - [24/Feb/2006:00:53:10 +0100] "GET /test.html HTTP/1.1" 304 - "-" "Mozilla/5.0 (X11; U; Linux i686; it-IT; rv:1.7.5) Gecko/20041221" > 2. Close the browser > 3. Reopen the browser > (3-1) Start LiveHTTPHeaders logging > (3-2) Load the same page (usually link click or open from bookmark) > (3-3) about:cache (both memory cache and disk cache) log2.txt and disk2.html are the attachments for this second test. No logs appears in the web server. > And, if possible, let us know URI where problem occured or occurs, or attach > the HTML on which problem occured, or attach simple/minimized test case. The problem is on a private LAN in a production environment. However I prepared a little page accessible via Internet: http://bnx.homelinux.net/test.html Many thanks, Luca

(In reply to comment #12) Thanks for quick attach of HTTP log and URI of simple case. Two date is written in Italian in your about:cache dislay. > Last modified: ven 24 feb 2006 00:53:10 CET > Expires: dom 13 ago 2006 10:37:04 CEST It looks; Italian / English Italian / English ven = venerd / Friday feb = febbraio / February => 2006/02/24(Fri.) CET dom = domenica / Sunday ago = agosto / August => 2006/08/13(Sun.) CEST CET : Central European Time / time zone indicator: +0100 CEST : Central European Summer Time / time zone indicator: +0200 (CET+1:00) Is it right? (My test result with Seamonkey 2006012909-trunk/Win-2K) No <meta> tag is found in your HTML, then no cache related <meta http-equiv="..."> tag is involved. No "Expires:" header was not sent by your server. Following is about:cache/Disk-Cache by my Seamonkey. - browser.sessionhistory.max_total_viewers = 0 - browser.sessionhistory.max_viewers = 0 - Time zone=JST:Japanese Standard Time=+0900. Now is 2/24, 11:19 AM in JST) > Key: http://bnx.homelinux.net/test.html > Last modified: 2006-02-24 10:41:14 > Expires: 2006-08-13 19:35:56 ("Last modified:" is update time of entry. Not "Last-Modified:" HTTP Header) When click link to your page : (Case-1) "Every Time I view the Page". browser.cache.check_doc_frequency = 1 Seamonkey requested nexts. > If-Modified-Since: Tue, 26 Jun 2001 08:34:01 GMT > If-None-Match: "1c44-2f1-3b3848f9" > Cache-Control: max-age=0 (Case-2) "When the page is out of date". browser.cache.check_doc_frequency = 3 No HTTP GET is issued. (Case-3) "Once per session". browser.cache.check_doc_frequency = 0 No HTTP GET is issued. (Case-4) "Never". browser.cache.check_doc_frequency = 2 No HTTP GET is issued. Max-age is defaulted to near 6 months? Or browser.cache.check_doc_frequency other than 1 is considered to be "Never"?

(In reply to comment #12) Luca, could you create 2nd/3rd test case at your site by adding meta tag? (2nd) <meta http-equiv="Cache-Control" content="max-age=0"> (3rd) <meta http-equiv="Cache-Control" content="max-age=(several seconds)">

(Additonal test result) If "Reload" is executed, HTTP GET with If-Modified-Since: is requested even when cache option is set to "Never".

Changing summary (adding "no Cache-Control:max-age")

(In reply to comment #13) > Two date is written in Italian in your about:cache dislay. > > Last modified: ven 24 feb 2006 00:53:10 CET > > Expires: dom 13 ago 2006 10:37:04 CEST > > It looks; Italian / English Italian / English > ven = venerd / Friday feb = febbraio / February => 2006/02/24(Fri.) CET > dom = domenica / Sunday ago = agosto / August => 2006/08/13(Sun.) CEST > CET : Central European Time / time zone indicator: +0100 > CEST : Central European Summer Time / time zone indicator: +0200 (CET+1:00) > Is it right? Yes, it is. Sorry, I forgot to unset LANG. > Max-age is defaulted to near 6 months? I think the expire date is calculated something like: cur_date+(cur_date-page_date)/10 > Or browser.cache.check_doc_frequency other than 1 is considered to be "Never"? I think "When the page is out of date" means when the client time go over the expiration date in the cache; instead, "Once per session" is like "never" but at least 1 time per session the page must be fetched (it could be also from cache, but not when neither Expires nor max-age are not set by the web server). I create the other 2 test pages: http://bnx.homelinux.net/test2.html <<-- max-age=0 http://bnx.homelinux.net/test3.html <<-- max-age=10000000 When "max-age" is set, the first time (in the session) the browser always get the page from the server (with if-modified-since). It could be a solution for my problem, but I think the automatic Expire date rule must be changed; I think the correct solution is to add a default maximum age (1 day?) in the case neither http nor meta headers appear from the web server. What do you think about? Thanks, Luca

(In reply to comment #17) > I create the other 2 test pages: > http://bnx.homelinux.net/test2.html <<-- max-age=0 > http://bnx.homelinux.net/test3.html <<-- max-age=10000000 > When "max-age" is set, the first time (in the session) the browser always get > the page from the server (with if-modified-since). With your test cases and logs, problem is now clear. Thanks. Confirming based on your test results and my problem recreation test result. > What do you think about? Sorry but I can say nothing about "what should be" because I don't know spec of HTTP 1.1 well. Darin Fisher, what should be?

> > Max-age is defaulted to near 6 months? > I think the expire date is calculated something like: > cur_date+(cur_date-page_date)/10 Luca, you were right. I've found Darin's description on this problem at last. See Bug 310656 Comment #6 and Bug 310656 Comment #7. Comments say: - This is working as designed. - This is typical heuristic written in RFC 2616. Darin Fisher wrote in the comment "I have often thought about improving", but I don't know wheter he is still thinking(and will continue to be thinking) about it or not. Question to Darin Fisher. According to Luca's comment #17, if max-age=10000000 is set, If-Modified-Since: is issued when session start(first access after restart of FF), even though it is not expired(I think working as designed and as RFC defines.) This indicates, I think, that internal settting of max-age="heristic expiration" can be solution for this bug. Is it true? CCing to Alfred Kayser(current assignee of Bug 310656).

RFC 2616 says ( http://www.ietf.org/rfc/rfc2616.txt ) ; > 13.2.2 Heuristic Expiration >(snip) and we encourage origin servers to provide explicit expiration times > as much as possible. > 14.46 Warning > 113 Heuristic expiration > MUST be included if the cache heuristically chose a freshness > lifetime greater than 24 hours and the response's age is greater > than 24 hours. Darin Fisher and Alfred Kayser, how about returning warnig header to such server that still doesn't send max-age even though "Encouragement by RFC 2616"?

Changing summary (Wrong cache expires date => Heuristic Expiration) Cache "once per session" is not honoured when restart of Firefox(session start), if Heuristic Expiration is used due to no Cache-Control:max-age & no Expires: in http-headers

*** Bug 327438 has been marked as a duplicate of this bug. ***

I've opened Bug 328605. Fix of Bug 328605 can be a solution of this bug.

(In reply to comment #20) > 14.46 Warning This was about warning from proxy server to client, so irreleveant here. (Elmar Ludwig, thanks for teaching me on it) Ignore my comment #20, please. Sorry for spam.

(In reply to comment #17) > http://bnx.homelinux.net/test3.html <<-- max-age=10000000 > > When "max-age" is set, the first time (in the session) the browser always get > the page from the server (with if-modified-since). Luca Bonissi, can you test "Expires: header only" case? > <meta http-equiv="Expires" content="2010 or 2061 or 3001(year of 'a space oddyssey's)"> and no "Cache-Control: max-age=...".

(In reply to comment #25) > Luca Bonissi, can you test "Expires: header only" case? > <meta http-equiv="Expires" content="2010 or 2061 or 3001(year of 'a space oddyssey's)"> and no "Cache-Control: max-age=...". The behaviour is the same as the "max-age" control. But I was wrong the last time: when "max-age" is set, the page is fetched from the server only after 2 session (2 browser restarts). The first time is fetched from the server, the 2nd from the cache, the 3rd from the server, the 4th from the cache and so on... but this is not a real problem. I think the solution to this problem could the to simulate "max-age" or manual "Expires" when using heuristic.

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258