Referring to some browser caching information, this paper summarizes its process through a graph.
The first time a browser initiates a web server
httpAfter the request, the server returns the requested resource and adds some caching fields to the response header, such as:
DateWait. The browser then requests the resource from the server to use it as appropriate.Strong cacheandNegotiation cache。
- Strong caching: Browsers get data directly from local caches without interacting with servers.
- Negotiation Caching: Browsers send requests to servers to determine whether local caching can be used.
- Connection and Difference: Both caching methods ultimately use local caching; the former does not need to interact with the server, and the latter does.
Let’s assume that the browser has accessed the server, the server has returned the header fields associated with the cache, and the browser has cached the related resources. Strong caching and negotiation caching are analyzed in the following figure:
The process shown in the red line in Figure 1 represents a strong cache. The user initiated a
httpAfter the request, the browser discovers that the cache of the requested resource already exists locally, and then begins to check whether the cache expires. There are two HTTP header fields that control the validity of the cache:
Cache-ControlThe browser determines whether the cache expires based on the following two steps:
- Check if the cache is available
max-ageInstructions, if any, use response message generation time
Date + s-maxage/max-ageObtain the expiration time and compare it with the current time（
s-maxagePublic cache servers for multi-user use;
max-ageDirectives, then comparisons
ExpiresThe expiration time and current time.
ExpiresIt’s an absolute time.
Be carefulIn HTTP/1.1, when the header field
max-ageDirectives, compared to the first field
ExpiresPriority will be given to
Here are a few more
no-cacheThis means that instead of using local caches, you need to use negotiation caches, i.e. confirm with the server whether the caches are available.
publicIndicates that other users can also use caching, which is suitable for the case of public caching servers.
privateIndicates that only specific users can use caching, which is suitable for the case of public caching servers.
After these two steps, if the cache has not expired, the return status code is
200If the cache expires, it enters the negotiation cache or the server returns new resources.
When the browser finds that the cache is out of date, the cache is not necessarily unusable, because the resources on the server side may still remain unchanged, so it needs to negotiate with the server to let the server decide whether the local cache can still be used. At this point, the browser will determine whether there is a cache or not.
Last-ModifiedFields, if not, initiate an HTTP request, and the server returns the resource based on the request; if there are two fields, add them to the request header
ETagIf fields are added,
Last-ModifiedAdd fields if you want to.Be careful:If sent at the same time
If-Modified-SinceFields, servers only need to compare
ETagIf the content is consistent, the server will return the status code if it thinks the cache is still available.
304The browser reads the local cache directly, which completes the negotiation process, i.e. the blue line in the graph; if the content is inconsistent, it returns other status codes and the requested resources as appropriate. The following process is explained in detail:
Both values are unique identifier strings allocated by the server for each resource.
- The browser requests resources, and the server adds them to the response header
ETagThe values are updated accordingly.
- When the browser requests resources again, it adds them to the request header
If-None-MatchFields whose values are in the last response message
- Servers will compare
If-None-MatchIf not, the server accepts the request and returns the updated resource; if the consistency indicates that the resource has not been updated, the return status code is
304Responses can continue to be cached locally. It should be noted that the response header will be added at this time.
ETagField, even if it does not change.
Both values are time strings in GMT format.
- After the browser first requests resources from the server, the server adds them to the response header
Last-ModifiedFields, indicating the last modification time of the resource;
- When the browser requests the resource again, it adds it to the request header
If-Modified-SinceField, whose value was in the last server response message
- Servers will compare
If-Modified-SinceIf not, the server accepts the request and returns the updated resource; if the consistency indicates that the resource has not been updated, the return status code is
304Responses can continue to use local caches, and
ETagThe difference is that the response header will not be added at this time.
ETagin comparison with
The following is quoted from: http Negotiation Cache VS Strong Cache
You may feel like using it.
Last-ModifiedIt’s enough for browsers to know if local cached copies are new enough and why they need to
ETagWhat about it?
ETagThe emergence is mainly to solve several problems.
Last-ModifiedMore difficult problems to solve:
- Some files may change periodically, but their content does not change (just the time of change). At this time, we don’t want the client to think that the file has been modified, but to restore it.
- Some files are modified very frequently, such as in less than seconds (for example, N times in 1s).
If-Modified-SinceThe granularity that can be checked is s-level, and this modification cannot be judged (or rather, it can’t be judged).
MTIMEIt can only be accurate to seconds.
- Some servers can’t get the exact last modification time of the file.
At this point, use
ETagCaching can be controlled more accurately because
ETagIs the unique identifier of the resource automatically generated by the server. Every time the resource changes, it generates a new one.
ETagIt can be used together, but the server will prioritize validation
Finally, a diagram is attached to illustrate the impact of user behavior on browser caching: