{"id":4263,"date":"2026-11-04T11:05:00","date_gmt":"2026-11-04T11:05:00","guid":{"rendered":"https:\/\/www.ucartz.com\/blog\/http-304-not-modified\/"},"modified":"2026-11-09T22:05:02","modified_gmt":"2026-11-09T22:05:02","slug":"http-304-not-modified","status":"publish","type":"post","link":"https:\/\/www.ucartz.com\/blog\/http-304-not-modified\/","title":{"rendered":"HTTP 304 Not Modified: What It Means and When It Is a Problem"},"content":{"rendered":"\n

HTTP 304 Not Modified means “you already have the latest copy”. A browser, CDN or crawler that has a file in its cache asks the server whether it has changed, usually by sending the file’s ETag or last-modified date. If nothing has changed, the server replies 304 with headers only and no body, and the client uses its cached copy. A 304 is not an error. It saves bandwidth and makes repeat visits faster. It only becomes a problem when visitors keep seeing old content after you have changed a file, or when you expected a 304 and always get a full 200.<\/p>\n\n\n\n

\"Terminal
A conditional request in practice: the first request returns 200 with Last-Modified, the second sends If-Modified-Since and gets 304<\/figcaption><\/figure>\n\n\n\n

What the 304 status code means<\/h2>\n\n\n\n

RFC 9110<\/a>, the HTTP standard, says a 304 indicates that a conditional GET or HEAD request “would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false”. In plain terms, the client said “send this only if it differs from my copy”, and it does not. The same section says a 304 ends with the headers: it cannot contain content.<\/p>\n\n\n\n

A client makes a request conditional with one of two headers, both built from what the server sent the first time:<\/p>\n\n\n\n

Server sends (first response)<\/th>Client sends back later<\/th>Server answers 304 when<\/th><\/tr><\/thead>
ETag: \"6abcaa5d-1a90\"<\/code><\/td>If-None-Match: \"6abcaa5d-1a90\"<\/code><\/td>The current ETag matches<\/td><\/tr>
Last-Modified: <date><\/code><\/td>If-Modified-Since: <same date><\/code><\/td>The file has not changed since that date<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

If both headers arrive, the ETag wins. RFC 9110 says a server must ignore If-Modified-Since when the request contains If-None-Match, because the ETag comparison is the more accurate test.<\/p>\n\n\n\n

See a 304 for yourself<\/h2>\n\n\n\n

We served a 6,800-byte stylesheet from nginx 1.31.6 (the nginx:alpine<\/code> Docker image) and requested it with curl 8.22.0. The first request is a normal 200 with both validators:<\/p>\n\n\n\n

$ curl -sI http:\/\/web\/style.css\nHTTP\/1.1 200 OK\nContent-Type: text\/css\nContent-Length: 6800\nLast-Modified: Wed, 30 Sep 2026 06:21:17 GMT\nETag: \"6abcaa5d-1a90\"<\/code><\/pre>\n\n\n\n
Sending the ETag back gives a 304, and the transfer is empty:<\/p>\n\n\n\n
$ curl -sI -H 'If-None-Match: \"6abcaa5d-1a90\"' http:\/\/web\/style.css\nHTTP\/1.1 304 Not Modified\nLast-Modified: Wed, 30 Sep 2026 06:21:17 GMT\nETag: \"6abcaa5d-1a90\"\n\n$ curl -s -o \/dev\/null -w '%{http_code} %{size_download} bytes\\n' -H 'If-None-Match: \"6abcaa5d-1a90\"' http:\/\/web\/style.css\n304 0 bytes<\/code><\/pre>\n\n\n\n
The same file without the header downloaded 6,800 bytes. If-Modified-Since<\/code> with the Last-Modified date also returned 304. Then we added one line to the stylesheet and sent the old ETag again:<\/p>\n\n\n\n
HTTP\/1.1 200 OK\nContent-Length: 6819\nLast-Modified: Wed, 30 Sep 2026 06:21:29 GMT\nETag: \"6abcaa69-1aa3\"<\/code><\/pre>\n\n\n\n
The ETag changed, so the server sent the whole new file. nginx builds the ETag for a static file from its modification time and size in hexadecimal (1a90<\/code> is 6800, 1aa3<\/code> is 6819). Apache does much the same: the FileETag<\/a> default is MTime Size<\/code>.<\/p>\n\n\n\n
Where you see 304 responses<\/h2>\n\n\n\n