Проверка Last-Modified

Проверка Last-Modified показывает, отдаёт ли сервер страницу с датой последнего изменения и отвечает ли он 304 при повторных визитах. В поле «Адрес страницы» можно ввести адрес целиком или домен. Домену без схемы подставляется https, а проверяется конечный адрес после всех переадресаций.

Как условный запрос экономит трафик

При первом заходе браузер получает страницу вместе с заголовком Last-Modified и запоминает дату из него. При следующем заходе эта дата уходит на сервер в заголовке If-Modified-Since. Сервер сравнивает её со своей датой изменения. Если страница не менялась, он отвечает 304 Not Modified без тела, и качать её заново не нужно; если менялась, приходит 200 с полным содержимым.

Проверка ходит на страницу несколько раз. Обычный заход забирает заголовки конечного ответа, условный по этой же дате должен вернуть 304, а условный по дате на секунду раньше — 200; если есть ETag, добавляется запрос по If-None-Match.

Полностью все заголовки ответа с разбором по смыслу показывает проверка HTTP-заголовков.

Заголовок есть, а 304 не приходит

Дата в ответе стоит, но на условный запрос сервер присылает 200 со всей страницей. Значит, сравнения дат на сервере нет, и заголовок работает вхолостую.

Зеркальная поломка выглядит иначе: на запрос по более ранней дате приходит 304. Такой сервер вообще не сверяет даты и отвечает 304 всем подряд, так что после каждой правки посетитель видит старую страницу.

Дата, которая меняется от захода к заходу, обесценивает заголовок полностью — условный запрос с ней никогда не сойдётся. Так ведут себя страницы, собираемые заново на каждый визит.

Ответ с Cache-Control: no-store запрещает хранить страницу, так что спрашивать «не изменилось ли» нечего. А Cache-Control: no-cache страницу хранит, но при каждом заходе отправляет условный запрос — ровно ради этого заголовок и нужен. После правки настроек сервера прогоните проверку заново и смотрите на ответ по более ранней дате: он покажет, заработало ли сравнение.

Правильная запись даты

Дата в Last-Modified записывается единственным правильным способом: Wed, 21 Oct 2015 07:28:00 GMT. Устаревшие форматы RFC 850 и asctime получатели ещё понимают, но сервер отдавать их не должен. Проверяйте конечный адрес, а не первый в цепочке переадресаций, — иначе увидите дату чужого ответа.

День недели в записи избыточен. Если он расходится с самой датой, заголовок собран вручную, а не сервером. Дата из будущего сверяется с заголовком Date того же ответа, часы проверки тут не опора. Дата, которая не разобралась, для получателей означает то же, что отсутствие заголовка, — так её и считайте.