Expires HTTP header. Why does the browser still contact the server?

Question

HTML

I started to get seriously interested in client-side optimization and came across a caching situation that I can't understand.

So the HTTP header Expires.

The value of this heading indicates from what date and time the document can be considered overdue, i.e. when it needs to be requested from the server again or to make sure it is up to date .

// Found here , many other sources repeat this position.

I started to study my sites and came across the fact that the pictures seem to be in the local cache and Expires is set for a couple of months, but Firebug and Fiddler show that they take time, and given their large number (100+) and the limited number of browser threads - this time is poured into seconds. Okay, I think, I'll see how and what happens on other, respected sites ... And there, it turns out everything is the same: requests are sent, answers are received.
On the main hub, I came across such a blatant horror:


Headings closer:

Firebug - Net - Waiting: 12.1 s

What does it get? The Expires header is set a few months ahead, i.e., for good, before this period expires, the content in the local cache could be considered valid and not pulled from the server, but in fact the browser goes to the server every time to get a 304 Not response modified. Yes, the response header is tiny, but the amount of resources, the connection speed, and the number of parallel threads from the browser to the domain level out this tinyness and turn the time of "useless" requests into seconds.

A reasonable question arises: how? Why? And what to do?

Answer 1

When you refresh a page with F5, browsers usually ask the server if the static resources have changed using the header If-Modified-Since(as you can see in your screenshot). But if you open the page again - close the tab, open a new one and enter the address - then the resources should be loaded from the cache, without a round-trip to the server.
This is such a specific page reload command that you give to the browser.

Answer 2

F5 press tie. You would still CTRL + F5 poking and complaining that all content from the server is being loaded.
For decency, switch between the two pages.

Answer 3

Are you sure that the browser goes to the site, and does not refer to the "cache engine" which transparently looks at the request headers for it and returns the result from the cache?

Answer 4

During the time spent on the issue, it was possible to raise the local server and see its logs. This, IMHO, is one of the few reliable ways to check whether there are requests or not.

Answer 5

So, locally.
1.html is a file without headers, pure Html-Header-body- img,src="1.php" ,…
1.php is a file with such content.

header('Expires: Thu, 26 Jul 2012 05:00:00 GMT');
header('Content-type: img/png');
header('Pragma: cache');
header('Cache-Control: store, cache, no-validate');

echo file_get_contents("1.png");

Two requests through chrome to the page.
server logs:

 sf.home: 127.0.0.1 [29/May/2012:00:27:55 +0400] "GET /Symfony/web/1.html HTTP/1.1" 200 230 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.52 Safari/536.5"
sf.home: 127.0.0.1 [29/May/2012:00:27:55 +0400] "GET /Symfony/web/1.php HTTP/1.1" 200 80600 "http://sf.home/Symfony/web/1.html" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.52 Safari/536.5"
sf.home: 127.0.0.1 [29/May/2012:00:28:07 +0400] "GET /Symfony/web/1.html HTTP/1.1" 304 - "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.52 Safari/536.5"

In the chrome console on the second request to 1.php, it says:
Status Code: 200 OK (from cache)

Answer 6

In the firebug, in addition to the "Headers" / "Headers" tab, there is a "Cache" / "Cache" tab. It displays information about where the object is stored, for example, for a picture from habra I got:
Data Size 94797
Device disk
Expires Fri May 27 2022 00:00:52 GMT+0400 (MSK)
Fetch Count 17
Last Fetched Tue May 29 2012 00 :00:53 GMT+0400 (MSK)
Last Modified Tue May 29 2012 00:00:53 GMT+0400 (MSK)
HTTP headers are only stored for the 1st access to the resource - for the picture above, I had the correct Expires parameters and the browser is fine cached.
Be sure to check with a sniffer whether the browser is really sending the request, try the same thing in another browser. If FF - then run it from under a new user, you may have changed some setting.

Answer 7

A simple example on the example of my site.
Without cache:
img-fotki.yandex.ru/get/6310/9010301.4/0_719cf_b4d2aa55_orig
With cache :
img-fotki.yandex.ru/get/6111/9010301.4/0_719d0_c1e2b15d_orig
smaller.

Answer 8

Here's what Google says:
If a user agent sends a request with "Cache-Control: max-age=0" (aka. "end-to-end revalidation"), then each cache along the way will revalidate its cache entry (eg . with the "If-Not-Modified" header) all the way to the origin server. If the reply is then 304 (Not Modified), the cached entity can be used.
You have a request with Cache-Control: max-age=0, it looks like you press Ctrl-F5 or the browser handles page refresh this way.