RFC: 2068
Оригинал: Hypertext Transfer Protocol - HTTP/1.1
Другие версии: RFC 2616
Категория: Предложенный стандарт
Дата публикации:
Авторы: , , , ,
Перевод: Алексей Симонов

14.24. If-Modified-Since

Поле заголовка запроса If-Modified-Since используется с методом GET, чтобы сделать его условным выражением: если запрошенный вариант не был изменен со времени, указанного в этом поле, объект не будет возвращен из сервера; вместо этого, 304 (не измененный) ответ будут возвращены без любого тела сообщения.

If-Modified-Since = "If-Modified-Since" ":" HTTP-date

Пример поля:

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Метод GET с заголовком If-Modified-Since и номером запросов заголовка Range, что идентифицированный объект быть переданным, только если он был изменен начиная с даты, данной заголовком If-Modified-Since.

Алгоритм для того, чтобы определить это включает следующие случаи:

  • a) Если запрос обычно заканчивался бы чем-нибудь кроме 200 (OK) состояние, или если переданная дата If-Modified-Since недопустима, ответ — точно то же самое что касается нормального GET. Дата, которая позже чем текущее время сервера, недопустима.
  • b) Если вариант был изменен начиная с даты If-Modified-Since ответ — точно то же самое что касается нормального GET.
  • c) Если вариант не был изменен начиная с правильной даты If-Modified-Since сервер ДОЛЖЕН возвратить 304 (Not Modified) ответ.

Цель этой возможности состоит в том, чтобы позволить эффективное обновление кэшируемой информации с минимальным количеством операционных издержек.

Обратите внимание: То, что поле заголовка запроса Range изменяет значение If-Modified-Since; см. раздел 14.36 за полные детали.

Те времена If-Modified-Since интерпретируются сервером, часы которого не могут быть синхронизированы с клиентом.

Обратите внимание, что если клиент использует произвольную дату в заголовке If-Modified-Since вместо даты, взятой от заголовка Last-Modified для того же самого запроса, клиент должен знать о факте, что эта дата интерпретируется в понимании сервера времени. Клиент должен рассмотреть несинхронизированные часы и округление проблем из-за других кодирований времени между клиентом и сервером. Это включает возможность условий состязания, если документ изменился между временем, его сначала запросили и Если-ModifiedSince дата последующего запроса, и возможность clockskew-связанных проблем, если дата If-Modified-Since получена из часов клиента без исправления на часы сервера.

Исправления для других основ времени между клиентом и сервером в лучшем случае приблизительны из-за сетевой задержки.

Страница 118 из 160

2007 - 2022 © Русские переводы RFC, IETF, ISOC.