![Firefox logo](https://assets-prod.sumo.prod.webservices.mozgcp.net/media/uploads/products/2020-04-14-08-36-13-8dda6f.png)
Firefox does not use cache on first load and reload
My webserver has a lot of images which will never change. So, I set Expires month forward in such cases:
Expires: Thu, 26 Jan 2012 02:01:25 GMT
Cache-control: public
Enough for IE 9, my server is not disturbed. But for FF8 and FF9 in following two scenarios my settings are ignored:
1) Close browser. Open browser, look at about:cache - all my files are on place. Open my page - server receives requests for all cached files. And nothing in request allowing server to detect that cache exists.
2) Press Reload button or F5. Again all cached files required. But now requests have Cache-Control: max-age=0 So, server has some idea about situation and probably can respond with 304.
Only 3) works as I proposed: after 1), open page once more - in the same or another tab. In this case, server receives only requests for files with restricted caching.
Current workaround: I add Last-Modified to response. In this case, I receive If-Modified-Since and can respond with 304. But I have hundreds of small images, so bandwidth for 304 is almost same as for 200 with complete file.
Browser cache settings - all defaults. I use numeric server addresses in current test environment like http://192.168.47.130:27374
I experimented with different modifications of Cache-Control response - without success.
And additional question - how can I make a line break in this editor? If I make a line break and empty line, I get line break and empty line. But if I make a simple line break, I get nothing in resulting text.
Edeziri
All Replies (8)
A good place to ask advice about web development is at the mozillaZine Web Development/Standards Evangelism forum.
The helpers at that forum are more knowledgeable about web development issues.
You need to register at the mozillaZine forum site in order to post at that forum.
If you press F5 Firefox will try to do a revalidation request.
If you press Ctrl+F5 Firefox will try to do an end-to-end load.
In these cases the loading behavior of Firefox is determined by the loadflags and not by the headers. So it is built-in like this.
There is a preference for loading behavior but it is only used for normal loads.
If you want to reduce the number of 304s that you have to send you can think about using "spriting". This means that you send big pictures and show little parts of it at the clientside using CSS.
To make a linebreak in the editor of the forum you can type a html break element. "< b r >" without the spaces.
https://support.mozilla.com/en-US/kb/markup-chart
Maybe, you are right and F5 acts as designed. There is no difference in request count for F5 and Ctrl+F5, the only difference - F5 requests contain If-Modified-Since, Ctrl+F5 do not. I think that IE interpretation is more correct - it's F5 does not send requests for non-expired cache.
And what do you think about my first scenario - close browser, open browser, enter address? Again FF sends requests for all cached items.
I'm not sure what is going on in the first scenario. You can try to make a http log with Firefox, then Firefox will tell why it's using the cache or not. Unfortunately, this logging is very buggy for me on Vista so most times I am not able to get some decent information from it. Maybe you have more luck.
https://developer.mozilla.org/en/HTTP_Logging
In Firefox loading URIs is a bit complex. Firefox has nineteen loadtypes, and each loadtype sets different loadflags. That makes it difficult to predict the loading behavior without studying the source-code.
You can also use the Live HTTP extension to see which headers are send to the server.
Thank you, knorretje. Had no problems with logging on 2003. Lot of lines, but I propose that critical part
0[220f140]: nsHttpChannel::OnCacheEntryAvailable [this=3f6f400 entry=5236740 access=3 status=0]
0[220f140]: nsHttpChannel::Connect [this=3f6f400]
0[220f140]: nsHTTPChannel::CheckCache enter [this=3f6f400 entry=5236740 access=3]
0[220f140]: nsHttpResponseHead::Parse [this=6b113c0]
0[220f140]: nsHttpResponseHead::ParseVersion [version=HTTP/1.1 200 OK]
0[220f140]: Have status line [version=11 status=200 statusText=OK]
0[220f140]: ParseContentType [type=image/gif]
0[220f140]: nsHttpResponseHead::MustValidate ??
0[220f140]: no mandatory validation requirement
0[220f140]: Not validating based on expiration time
0[220f140]: nsHTTPChannel::CheckCache exit [this=3f6f400 doValidation=1]
As I understand, all partial checks say that cache is good. But ending doValidation=1, probably, means that request will be sent. Do not see any reason.
Thank you, cor-el. As it is my server, I see all headers it receives. No need in Live HTTP.
Hello mahris,
You are right, doValidation=1 means a request will be send.
"Not validating based on expiration time" means that the cache is good and doValidation is zero. On line later doValidation suddenly is one and the cache is not good anymore. If I look on MXR I can find two possible reasons:
- A problem with the If-Match header (2660)
- Not trusting the cache because it was filled in a previous session (2672)
http://mxr.mozilla.org/mozilla-beta/source/netwerk/protocol/http/nsHttpChannel.cpp#2650