Strong cache

Forced caching means that when a client requests it, it first accesses the cache database to see if the cache exists. If present, return directly; If it does not exist, request the real server and write the response to the cache database.

Mandatory cache Settings

Fields that can cause forced caching are cache-Control and Expires.

1.Expires

This is an HTTP 1.0 field that represents the cache expiration time, and is an absolute time (current time + cache time), such as

expires: Wed, 07 Jul 2021 07:23:29 GMT
Copy the code

The expiration time set in the server response header to tell the browser not to come to the request until this time!

Existing problems:
  • The browser uses the local time as reference. The local time cannot be trusted and may be manually changed, resulting in cache invalidity
  • The file cannot be updated because it has changed on the server but has not reached the expiration date set by the browser
2.Cache-control

Cache-control A generic header field used to specify directives to implement caching in HTTP requests and responses. Cache directives are one-way, which means that directives set in the request are not necessarily included in the response. The following list lists some common instructions, refer to MDN for more information

Cache request instruction

Cache-Control: max-age=345345

Cache-control: no-cache

Cache-control: no-store

Cache response instruction

Cache-control: no-cache

Cache-control: no-store

Cache-control: public

Cache-control: private

Cache-Control: max-age=5435354353

Cache instruction interpretation
  • No-cache: Forces the cache to submit the request to the original server for validation (negotiated cache validation) before the cache copy is published.
  • No-store: no cache is used
  • Private: The private cache can cache the response content, for example, the local browser of the user.
  • Public: indicates that the response can be cached by any object, including the client that sent the request, the proxy server, and so on
  • Max-age: Sets the maximum period during which the cache is stored, after which the cache is considered expired (in seconds). In contrast to Expires, time is the time relative to the request.

If no-cache or max-age=0 is specified, must-revalidate indicates that the client can cache the resource. Each time a cache resource is used, it must be validated again.

Negotiate the cache

Negotiation cache is a process in which the browser sends a request to the server with the cache ID after the cache is invalid, and the server decides whether to use the cache based on the cache ID. There are two main situations:

  • The negotiated cache takes effect, returning 304 and Not Modified
  • Negotiation cache invalid, return 200 and request result

Negotiation cache Settings

Negotiated caching can be implemented by setting two HTTP headers: Last-Modified and ETag.

1. The last-modified and If – Modified – Since

When the browser accesses the resource for the first time and the server returns the resource, the last-Modified header is added to the response header, whose value is the Last modification time of the resource on the server. The browser caches the file and header after receiving it.

Last-Modified: Fri, 22 Jul 2016 01:47:00 GMT
Copy the code

The next time the browser requests the resource, the browser detects a last-Modified header and adds if-modified-since, which is the last-modified value; When the server receives the resource request again, it compares the value in if-modified-since with the last modification time of the resource in the server. If there is no change, it returns 304 and an empty response body, reading directly from the cache. If the time of if-modified-since is less than the time of the last modification of the resource on the server, the file has been updated, and the new resource file and 200 are returned

But last-Modified has some drawbacks: If the file is opened locally, last-Modified will be Modified even if the file is not Modified. The server will fail to hit the cache and send the same resource because last-Modified can only be measured in seconds. If the file is Modified in an imperceptible amount of time, The server will assume that the resource is still hit and will not return the correct resource

Since the cache is not sufficient based on the file modification time, can the cache policy be determined directly based on the file content modification? ETag and if-none-match were introduced in HTTP / 1.1

2. The ETag and If – None – Match

An Etag is a unique identifier (generated by the server) that is returned to the current resource file when the server responds to a request. The Etag is regenerated whenever the resource changes. When the browser sends a request to the server next time it loads a resource, it will add the Etag value returned last time to if-none-match in the request header. The server only needs to compare the if-none-match value sent by the client with the Etag of the resource on the server. It is a good idea to determine whether the resource has been modified relative to the client. If the server finds that the ETag does not match, it sends the new resource (including the new ETag) to the client in a regular GET 200 packet return. If the ETag is consistent, 304 is returned to inform the client to use the local cache directly.