HTTP cache-related fields
1. General fields
The field names | paraphrase |
---|---|
Cache-Control | Control the specific behavior of the cache |
Pragma | HTTP1.0 legacy field that enforces validation caching when the value is “no-cache” |
Date | Date and time the message was created (used in the heuristic caching phase) |
2. The response field
The field names | paraphrase |
---|---|
ETag | The unique identity of the resource generated by the server |
vary | Proxy server cache management information |
Age | How long the resource is stored in the cache proxy (depending on the size of max-age and s-maxage) |
3. Request field
The field names | paraphrase |
---|---|
If-Match | A conditional request that carries the ETag of the resource from the previous request, which the server uses to determine whether the file has new changes |
If-None-Match | In contrast to if-match, the server uses this field to determine whether the file has new changes |
If-Modified-Since | Check whether the modification time of two resource accesses is the same |
If-Unmodified-Since | Check whether the modification time of two resource accesses is the same |
4. Entity fields
The field names | paraphrase |
---|---|
Expires | Tell the client the absolute time when the resource cache will expire |
Last-Modified | The time when the resource was last modified |
Negotiation cache (304)
If-modified-Since/Last-Modified
- The server checks the request header when the browser sends a request
request header
The inside of theIf-modified-Since
, if the last modification time is the same, return 304, otherwise return header (response header
addlast-Modified
And returns data (response body
).
if-modified-since:Wed, 31 May 2017 03:21:09 GMT
if-none-match:"42DD5684635105372FE7720E3B39B96A"
Copy the code
If-None-Match/Etag
- When the browser sends a request, the server checks the request header (
request header
The inside of the)if-none-match
Hash algorithm (For example nodejs: cryto createHash (' sha1)
) generated content summary character comparison, the same is returned directly304
Otherwise return the header (response header
addetag
Property is the current content summary character and returns the content.
etag:"42DD5684635105372FE7720E3B39B96A"
last-modified:Wed, 31 May 2017 03:21:09 GMT
Copy the code
The request header’s last-Modified date matches the response header’s last-Modified date. If the request header’s hash matches the etag of the response header, Status Code: 304 is returned
Strong cache (200 from cache)
-
If Expires is set (XX Expires) or cache-control (http1.0 not supported) (XX Expires) and does not expire, from Cache does not issue a request if it hits the Cache. Pressing (e.g. CTRL + R) initiates the request, but returns 304 unchanged if it has not changed, or new if it has changed. Max – age > Expires.
-
Expires /cache-control Although expires/ Cache-control is a strong cache, the cache negotiation strategy is still adopted when the refresh behavior is actively triggered by the user. The refresh behavior actively triggered includes clicking the refresh button, right-clicking refresh, F5 refresh, CTRL + F5 refresh, etc.
-
Of course, if disable cahce is selected in the console, the latest content will be requested anyway (304 negotiated cache, strong cache will not work), because 1. No local cache is checked. 2. The request header has neither if-modified-since nor if-none-match for the server to determine. If you press Enter for an address entered in the address bar, the request header for that address (only the URL) will be cache-contro:max-age=0, so the strong cache will not be hit, but the address clicked through the link will be hit
-
Chrome ://view-http-cache/
The difference between
- Trigger 200 from cache:
- Click the link directly to visit
- Enter the url and press Enter to access it
- Qr code scanning
- Trigger 304:
- Triggered when the page is refreshed
- Triggered when a long cache is set but Entity Tags are not removed
The flow chart
Ps: If there are mistakes, please correct them
HTTP cache — 304 and 200 from cache
GayHub: wclimb