Last Modified Checker

The Last-Modified check shows whether the server sends the page with a last-modified date and whether it answers 304 on repeat visits. In the "Page URL" field you can enter a full address or just a domain. A domain without a scheme gets https added, and the final URL after all redirects is the one checked.

How a conditional request saves traffic

On the first visit the browser receives the page along with the Last-Modified header and remembers the date from it. On the next visit that date goes back to the server in the If-Modified-Since header. The server compares it with its own modification date. If the page has not changed, the server answers 304 Not Modified with no body, so there is nothing to download again; if it has changed, a 200 with the full content arrives.

The checker visits the page several times. A regular visit takes the headers of the final response, a conditional request with that same date should return 304, and a conditional request with a date one second earlier should return 200; if there is an ETag, a request with If-None-Match is added.

To see every response header with an explanation of each one, run the HTTP headers check.

The header is there, but no 304 arrives

The date is present in the response, but on a conditional request the server sends 200 with the whole page. That means the server does not compare dates, and the header does nothing.

The mirror-image breakage looks different: a request with an earlier date gets 304. Such a server never checks dates at all and answers 304 to everyone, so after every edit the visitor keeps seeing the old page.

A date that changes from visit to visit makes the header worthless, because a conditional request can never match it. Pages rebuilt from scratch on every visit behave this way.

A response with Cache-Control: no-store forbids storing the page, so there is nothing to ask "has it changed" about. Cache-Control: no-cache does store the page, but sends a conditional request on every visit, and that is exactly what the header is for. After changing the server settings, run the check again and look at the answer for the earlier date: it will show whether the comparison started working.

The correct date format

The date in Last-Modified is written in one correct way: Wed, 21 Oct 2015 07:28:00 GMT. Receivers still understand the obsolete RFC 850 and asctime formats, but a server should not send them. Check the final URL, not the first one in the redirect chain, or you will see the date of someone else's response.

The day of the week in the record is redundant. If it disagrees with the date itself, the header was assembled by hand rather than by the server. A date from the future is compared against the Date header of the same response, not against the checker's clock. A date that failed to parse means the same to receivers as the absence of the header, so treat it that way.