Understanding of HTTP 304)

Recently, I worked with my colleagues on the Web cache issue and further understood HTTP 304.

The standard interpretation of 304 is: the not modified client has a buffered document and sends a conditional request (generally, the IF-modified-since header is provided to indicate that the customer only wants to update the document than the specified date ). The server tells the customer that the original buffer documentation can still be used.

If the client finds that the cached file contains last modified when requesting a file, the request contains if modified since, which is the last modified of the cached file. Therefore, if the request contains if modified since, it indicates that the client has been slowed down. You only need to determine the time and the modification time of the Current requested file to determine whether to return 304 or 200. For static files, such as CSS and images, the server automatically compares last modified with if modified since to complete caching or updating. However, dynamic pages are dynamically generated pages that often do not contain the last modified information, so that browsers and gateways do not cache them, that is, a 200 request is completed every time a request is made.
Therefore, for dynamic page cache acceleration, first add the last modified definition to the HTTP header of response, then, 200 or 304 is returned Based on the if modified since in the request and the Update Time of the requested content. Although a database query has been performed when 304 is returned, more database queries can be avoided, and no page content is returned, instead of an HTTP header, this greatly reduces bandwidth consumption and improves user experience.
When these caches are valid, you can view a request through httpwatch and get the following result:
The first access 200
Click the second access (cache)
Press F5 to refresh 304
Press Ctrl + F5 to forcibly refresh 200
If so, the cache is actually valid. The above is my understanding of HTTP 304.