The HTTP server should tell the client how long the message can be cached. In this time range, the message content is fresh (FRESH ), the server uses the two response headers to tell the client:
1. expires (expired)
This header is mainly used in http1.0 and specifies the specific time point of the document "Expiration". Beyond this time, it is deemed that the document is not up-to-date. The time format used for this header is GMT, as shown below:
Expires: Sun Mar 20 13:21:12 GMT 2013
The problem with this header is that the client and the server need to synchronize the clock, but this is a very tricky problem, because the server and each client cannot run like Network Time Protocol at any time (Network Time Protocol, NTP) for clock synchronization.
To illustrate the problem caused by time synchronization, suppose:
The server returns an HTTP Response Message and sets the expires to: Sun Mar 2010:00:00 GMT 2012, which indicates that the client has provided this document before Mar 20 10:00:00 GMT 2012 and can be used directly.
But how does the client determine it? The expiration time set by the Expires header is actually set by the server. Therefore, the expiration time is calculated based on the server time as the benchmark, but the response must arrive at the client, the client cannot know the time of the server at this time. Therefore, the client can only judge based on the client's own time reference. There are three situations:
1. Synchronize the clock between the client and the server. At this time, read the current time of the client and compare it with the expires time. If expires> = current time of the client, the document is considered to have not expired, you can continue to use it.
2. If the client time is faster than the server time, the comparison will shorten the cache validity period. In extreme cases, the cache will become invalid, if the effective cache time set by the server is 10 minutes, and the client is 10 minutes earlier than the server, the response has expired;
3. If the client is slower than the server time, the effective response cache time will be longer. In extreme cases, data cannot be refreshed in time due to long cache time.
In summary, there is a big problem in using expires absolute time to control the cache. In the new http1.1 version, the new Response Header cache-control is used, use relative time to define the expiration mechanism, so that the client and server do not need to consider the problem of time synchronization.
Ii. cache-control
The cache-control header can be used in seconds to specify the maximum validity period of a document-fromAfter the document leaves the serverThe total time in use is not synchronized with the clock, so more accurate results can be given.
In fact, the cache-control header is like its name. It is not only used to control the validity period or expiration, but is actually a comprehensive header that controls the cache and supports various commands, it can also be used in HTTP requests and responses.
Message Type |
Command |
Description |
Request |
No-Cache |
Do not directly use cached copies (even if the cache has not expired). Instead, you must re-verify the cached copies to the server before returning the results. |
Request |
No-store |
Do not return cached copies of documents or save server responses. |
Request |
Max-age |
The cached documents cannot exceed the specified validity period. |
Request |
Max-stale |
The returned documents can expire (based on the expiration information provided by the server), but cannot exceed the expiration value specified in the command. |
Request |
Min-fresh |
The returned documents must be kept fresh at least within the specified time. That is, the validity period of the document must be greater than or equal to the sum of Min-fresh + current time. |
Request |
No-Transform |
The document cannot be converted before being sent |
Request |
Only-if-cached |
You do not need to contact the original server if the file is cached. |
|
|
|
Response |
Public |
The response can be cached by any server |
Response |
Private |
The response can be cached, but can only be accessed by a single client. |
Response |
No-Cache |
If this command is accompanied by a header list, the content can be cached and provided to the client, but the list of headers must be deleted first; If no header is specified, the cached copy cannot be provided directly to the client before it is re-verified to the server. |
Response |
No-store |
The response cannot be saved. Therefore, cache is not allowed. It is mainly used in some sensitive responses. |
Response |
No-Transform |
The response cannot be modified in any form before it is provided to the client. |
Response |
Must-revalidate |
The response must be re-verified to the server before being provided to the client. Similar to no-Cache |
Response |
Proxy-revalidate |
The shared cache must be re-verified with the original server before it is provided to the client; Private cache can ignore this Instruction |
Response |
Max-age |
Specifies the maximum time that a document can be cached and its freshness. |
Response |
S-max-age |
Specify the maximum time for using a document as a shared cache (if the max-age command exists, this command prevails ); Private cache can ignore this Instruction |
For example, if you press CTL + F5 (Force refresh) in the browser and capture packets, you can find that the request sent by the Browser contains the following request header:
Cache-control: No-Cache
Pragma: No-Cache