The 304 Not Modified Header is sent by servers to trigger caching mechanisms in the browser – this in turn lowers the bandwidth usage of both the client and the server.
Typically a browser will request a resource and save it in its cache, on the next request of the same resource, the browser will send a IF-MODIIED-SINCE header along with its GET Request, the CMS on the server-side would then check if the requested resource has been changed after the IF-MODIFIED-SINCE date provided by the browser – if this is not the case, a 304 Not Modified will be delivered, and the browser should instead load the resource from its cache.
The below is a HTTP GET Request, as performed by a browser, followed by a Status Code delivered by the server.
Request URL:http://brugbart.com/http-304-not-modified Request Method:GET Status Code:304 Not Modified
When delivering a 304 response, no response body should be sent along with the headers.
Caching of Static Files
Caching of static files are typically controlled by the HTTP server, while dynamic resources will need to be controlled programmatically.
If a static file has not been changed, the server will usually automatically respond with a HTTP 304 response code.
Caching of Dynamic Resources
Even when caching of resources is accounted for in the code, there may still be a problem if the code itself is updated – this is where the Etag header comes in. The Etag header is usually just a hash of the filesize of the script generating the resource – if the Etag changes, or the IF-MODIFIED-SINCE date doesn't match the current timestamp, the server will just respond with a standard 200 OK Header.
Caching of dynamic content can be improved even further than just using the 304 Not Modified header, such as caching the generated pages, eliminating the need to create the same content repeatedly.