HTTP Authoritative Guide----caching

Process Steps for caching:

1, receive----cache read the arrival request message from the network
2, parsing----cache to parse the message, extract the URL and a variety of headers
3. Query----cache to see if a local copy is available, and if not, get a copy (and save it locally)
4. Freshness detection----cache to see if the cached copy is fresh enough, and if not, ask the original server for any updates
5. Create response----The cache will build a response message with the new header and the cached body
6. Send----cache sends the response back to the client over the network
7, log----Cache optional Create a log file entry to describe the business

Note: 1, the HTTP Response message header field, with Cache-control, age, expires and other headers to indicate freshness information related content, through the Via header indicates that the entity content is provided by the proxy cache.

2, the cache should not adjust the date header, date header represents the original server originally generated the date of this object, so that the client can see the original date of the resource generation.

To access www.sina.com.cn with Google Explorer : The message is as follows:

Note here: the Date field description was obtained on the Nginx server at 2016.9.30 8:54, and I requested the time also, for 5:01 minutes, X-cache should be the server-side custom extension header, indicating the name of the cache server.
The expires field refers to the absolute expiration time, which should be well understood, whereas the max-age=60 of the Cache-control field refers to the relative expiration time, in seconds, or 60 seconds.
The above explanation, Sina Network information update time should be about 9 in the morning. After that is the time to check, every time we request, the cache server should go to the original server to check the information, see if the document has changed, "Server re-authentication." It is clear that the document has expired, but the original server did not make any changes to the document (should return 304 not modified), but why did the cache server not modify the expiration time? According to the book, the cache server validation should be updated on the expires header, but not here. (Why?) )

Here's another word about validation: There are two ways to verify :
1, through the first if-modified-since:<date> re-verification
date is specified in last-modified and should be returned if not modified 304 not modified
2, through the first if-none-match:<etag> re-verification
ETag is the version information of the entity or "fingerprint information", if not modified, should return 304 not modified, if modified will return to the OK, and attach a new etag. (The entity label is re-verified to compensate for the lack of the sub-second condition when the server-supplied document is modified, not enough in seconds)

It is noted in the book that applications in http/1.1 should use Cache-control:no-cache, indicating that each cache server should be re-authenticated with the original server. (But this is not the case, tried most of the site, such as Sina, Sohu, Baidu Network, CSDN, blog Park, Fighting fish, the whole world, only fighting fish and all two live sites do not point out the Cache-control, other points of value are max-age)

To control the priority descending order of the cache:
Cache-control:no-store---> No-cache---> Must-revalidate---> Max-age---> expires:<date> ----> Do not append cache expiration information to let the cache determine its own expiration date.

Here is an easy to remember approximate cache GET request Flowchart:

HTTP Authoritative Guide----caching