User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:126.96.36.199) Gecko/2010031422 Firefox/3.0.19 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:188.8.131.52) Gecko/2010031422 Firefox/3.0.19 Static files (like css, js, png, jpg, ...) get cached and firefox 3.x takes the files from cache forever, means over days and OS restarts. Reproducible: Always Steps to Reproduce: 1. Open FF 3.x load a dynamic php-page that includes css and js - files 2. Change the css and js - files on the server (optional: restart server/serverOS) 3. Restart clientOS or shutdown client and wait for 1 to infinite days 4. Start client and open FF 3.x load that page again Actual Results: The php-pages are retrieved from server, the css and js files are retrieved from cache. If functions and layouts in the php+css+js files are changed the whole page is unusable. Only [STRG]+[F5] will load the new static files. Expected Results: At least FF 3.x should check once a session or once a day if the static files have been changed. FF 3.x should not cache the static files forever. There are many hints for this. For example to add a version behind static files: /css/foo.css?bar=1.0 This is ridiculous since there are rfc standards for that and a browser should do this work, not the web-developer. I can not understand why this ist a major problem since FF 3 cames out. I can not understand why there is no solution for this bad behavior.
Please post the http header for those files ? A http log with a previously cleared cache and a reload with enabled logging would be great. https://developer.mozilla.org/en/HTTP_Logging You can attach it using the "add an attachment" link above.
Hello, I apologise the late response, I am very busy at the moment. I had no time to investigate it in deep. 1) With a cleared cache I can not reproduce it. It seems that the problem occurs only after a certain period of caching. 2) After I have installed firebug it is also very difficult to reproduce it on our server (I do not understand why). Nevertheless, at this time I found a client in our LAN who used a old js file which was changed 3 (!) weeks ago (FF 3.6.11). I can only provide whats in apache's log for this client -> no GETs on css+js. (so firefox even can not know that there was something changed). 3) I should also provide you the certian circumstances: - We have a apache server in our LAN with many different applications on it. - The server is called with http://192.168.10.6:12345/ - In the doc-root there is an app. (the first developed) - All other app. are in subfolders. - Because this thing is grown over years it is a very mess. - We decided to get it somehow into one big app. But unfortunately with little progress. - But we made a policy for new app. So they have to follow a certain filestructure with min. requirements. Let me explain the file structure (in / is the main app) / -/css --main.css -/js --main.js -index.php -/app2 --/css ---main.css --/js ---main.js --index.php -/app3 --/css ---main.css --/js ---main.js --index.php etc. So there are many files and folders with identical names in the same "domain" but unter different locations. Maybe this is the problem. I will provide more information if i have more time for that.
> at this time I found a client in our LAN who used a old js file which was > changed 3 (!) weeks ago What HTTP headers is that JS file sending right now? See comment 1.
OK. So the server sends a Last-Modified and a Date, but no Expires or Max-Age. In this situation, the HTTP spec says that the client should use a heuristic to determine the expiration time (that is, the time at which the client should next make a GET request instead of just reading from cache). The heuristic we use is that the content is valid for a time equal to (Date - Last-Modified)/10 starting now. In the example above, that would be for 2 seconds from the receipt of the response. But for a file that hasn't been modified in 30 weeks, the validity period would be computed at 3 weeks. So how long was that js file unmodified before being modified?
no response, please reopen if this still happens