Big Liar PHP Cache Header

What is the difference between a 304 request mechanism and 200? When I look at the 304 request in Fiddler, I think of this problem, and I thought about the 304 request mechanism.

We put a file on the nginx ourselves, test.png. Access can be made using the following address:

Http://test.yejianfeng.com/test.png

The Nginx configuration file is as follows:

This etag is closed because Nginx is the default open etag, instructions see Ngx_http_core_module (http://nginx.org/en/docs/http/ngx_http_core_module.html).

Now that I've closed the ETag, the HTTP request for this test.png is as follows:

You can see that the response Header here last-modified is not set to expire, so last-modified is not in effect. With no other related cache header, this time, the browser will not cache this page. So, whether you paste Url,f5 or ctrl F5, the page requests Cache-control is set No-cache, so the server response is 200.

Below, modify the Nginx configuration to add a expires 1d:

The restart Nginx,http request is as follows:

Can see here expires than date more than a day, so is the server to tell the client, you give me a local cache a day.

Then use F5 at this time:

Return is 304, this time, is the local browser cache this page, send the condition request to the service side, the condition request inside with a if-modified-since, the client asks the server side, this file browser side has the cache, if your server file at this point in time has changed, Just send me a changed file and send a 304 if you don't have one.

Here's another question, how is this last-modified set? It is the last time the file was modified on the server.

The 8 hours in the middle of the 15:31 and last-modified 07:31 in the figure are time zone-induced.

We touch to modify the last modified time of this file:

And then F5 this URL:

The server returns 200, and Last-modified has also been modified. This is a good understanding.

If I didn't use F5, I would just paste the URL directly into the browser? At this point, the browser's behavior is to use the local cache if there is a local cache, and if there is no cache locally, request the server.

The experiment we can do is this:

1 Opening fiddler

2 Ctrl + F5, this time fiddler more than a 200 response

3 F5, this time fiddler more than a 304 response

4 Open a new tab, enter Url:http://test.yejianfeng.com/test.png in the address bar this time will find fiddler and no request

5 Ctrl + F5, this time fiddler one more 200 responses

So here you can verify the previous article: the HTTP Cache-related header (http://www.cnblogs.com/yjf512/p/3244882.html) says three kinds of refresh behavior.

Go back to the cache header, empty your browser's cache, remove the expire settings, and open the ETag

First time visit:

See the ETag is used here, the etag is equivalent to a version number, the HTTP protocol does not specify the ETag algorithm, its specific calculation depends on the Web server itself. The ETag also has a distinction between ordinary and weak etag (HTTP://EN.WIKIPEDIA.ORG/WIKI/HTTP_ETAG).

When you visit the second time:

The client sends the request to have a if-none-match, indicates the client asks the service side, if you this side of this file's tag or the XXXXX, returns 304, is not the word returns 200.

So If-none-match + ETag is a cache that can control the file in the browser.

On the cache header, some are client-side:

Cache-control

If-modified-since

If-none-match

Some are service-side:

Expire

Last-modified

ETag

A description of these headers can be seen in this article: HTTP Cache-Related headers (http://www.cnblogs.com/yjf512/p/3244882.html)

OK, here's a scenario:

We again nginx do a rewrite, all JS rewrite to myjs.php this script, then ask a question, JS in F5 when will send conditional request, this condition request will trigger PHP?

The answer is yes. The conditional request is also a normal PHP request that will trigger PHP. This time if you need to return 304, you need to if-modified or If-none-match in the PHP program to judge.