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

14.20. ETag

Поле заголовка объекта ETag определяет тэг объекта для связанного объекта. Заголовки, используемые с тэгами объекта, описаны в разделах 14.20, 14.25, 14.26 и 14.43. Тэг объекта может использоваться для сравнения с другими объектами от того же самого ресурса (см. раздел 13.3.2).

ETag = "ETag" ":" entity-tag

Примеры:

ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

14.21. Expires

Поле заголовка объекта Expires дает дату/время, после которой ответ должен рассматриваться устарелый. Устарелый элемент кэша не может обычно возвращаться кэшем (или кэш прокси-сервера или кэш user agent), если он сначала не утвержден с сервером происхождения (или с промежуточным кэшем, у которого есть новая копия объекта). См. раздел 13.2 для дальнейшего обсуждения модели expiration.

Присутствие поля Expires не подразумевает, что оригинальный ресурс изменится или прекратит существовать в, прежде, или после того времени.

Формат — абсолютная дата и время как определено HTTP-date в разделе 3.3; он ДОЛЖЕН быть в формате RFC1123-date:

Expires = "Expires" ":" HTTP-date

Пример его использования

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Обратите внимание: Если ответ включает поле Cache-Control в директиву max-age, та директива отменяет поле Expires.

HTTP/1.1 клиенты и кэши ДОЛЖЕН обработать другие недопустимые форматы даты, особенно включая значение "0", как в прошлом (то есть, "уже истек").

Отмечать ответ как "уже истекается," сервер происхождения должен использовать дату Expires, которая равна значению заголовка Date. (См. правила для вычислений expiration в разделе 13.2.4).

Чтобы не отметить ответ как "никогда, окончания функционирования," сервер происхождения должен использовать дату Expires приблизительно один год со времени ответ, отправляют. HTTP/1.1 серверы не должен отправить датам Expires больше чем один год в будущем.

Присутствие поля заголовка Expires со значением даты некоторого времени в будущем на ответе, который иначе по умолчанию был бы некэшируемым, указывает, что ответ — cachable, если не обозначено иначе полем заголовка Cache-Control (раздел 14.9).

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