If-Modified-Since: date based conditional requests

The client echoes a date it previously received in Last-Modified. The server compares it with its current modification time and, if nothing is newer, replies 304 with headers only. It is the oldest revalidation mechanism in HTTP and the one most likely to be understood by an ancient client or an intermediary that ignores entity tags.

It is defined only for GET and HEAD. A conditional write is a different problem with a different answer, and the header for that is If-Unmodified-Since, which fails with 412 rather than succeeding with 304. Servers are required to ignore this header on other methods rather than guessing what was meant.

Servers must also ignore it when the request carries If-None-Match, and must ignore an unparseable date rather than treating it as the beginning of time. Both rules exist so that a malformed or contradictory conditional request degrades into a normal full response rather than into a wrong 304.

The one second resolution is the practical limit. A resource that changes several times a second cannot be revalidated correctly with dates alone, and the client will be told 304 while holding a version that is already superseded. That is the case an ETag exists for.