Поле Expires |
||
< Поле ETag | Содержание | Поле From > |
Поле заголовка объекта Expires содержит дату/время с момента, когда отклик может считаться устаревшим. Устаревшая запись в кэше в норме не должна посылаться кэшем (а также прокси кэшем и кэшем агента пользователя), если только она не будет сначала перепроверена с помощью исходного сервера (или с помощью промежуточного кэша, который содержит свежую копию объекта). Дальнейшее обсуждение модели контроля пригодности записей содержится в разделе 12.2 Присутствие поля Expires не предполагает, что исходный ресурс изменит или удалит объект по истечении указанного времени. Формат абсолютной даты и времени описан в разделе 2.3 Он должен следовать рекомендациям документа RFC1123: Expires = "Expires" ":" HTTP-date Примером реализации формата даты может служить Expires: Thu, 01 Dec 1994 16:00:00 GMT Замечание. Если отклик содержит поле Cache-Control с директивой max-age, то эта директива переписывает значение поля Expires. Клиенты HTTP/1.1 и кэши должны рассматривать некорректные форматы даты, в особенности те, что содержат нули, как относящиеся к прошлому (то есть, как "уже истекшие"). Для того, чтобы пометить отклик, как "уже с истекшим сроком", исходный сервер должен использовать дату Expires, которая равна значению заголовка Date. (Правила вычисления времени истечения пригодности записи смотри в разделе 12.2.4.) Для того, чтобы пометить отклик как "всегда пригодный", исходный сервер должен использовать дату Expires приблизительно на один год позже момента посылки отклика. Серверы HTTP/1.1 не должны посылать отклики с датами в поле Expires, которые устанавливают время жизни более одного года. Присутствие поля заголовка Expires со значением даты, относящейся к будущему, означает, что они могут быть занесены в кэш, если только не указано обратного в поле заголовка Cache-Control (раздел 13.9). |
||
RFC 2068 |