Expires: と Cache-Control: max-age との併用
0」を含む構文的に正しくない値を過去の日付が指定されたものと解釈しなければ
This line, if present, is in a legal USENET date format. It specifies a suggested expiration date for the message. If not present, the local default expiration date is used. This field is intended to be used to clean up messages with a limited usefulness, or to keep important messages around for longer than usual. For example, a message announcing an upcoming seminar could have an expiration date the day after the seminar, since the message is not useful after the seminar is over. Since local hosts have local policies for expiration of news (depending on available disk space, for instance), users are discouraged from providing expiration dates for messages unless there is a natural expiration date associated with the topic. System software should almost never provide a default "Expires" line. Leave it out and allow local policies to be used unless there is a good reason not to.
"Expires" (期限切れ)
行をほとんど絶対に用意しておかないのが良いです。
この行を適切な理由が無い限り使わずに、 local の方針が使われるようにして下さい。
編注 :
The Expires entity-header field gives the date/time after which the
{1945} entity{2068} response{2068} should be{2616} is considered stale.{1945} This allows information providers to suggest the volatility of the resource, or a date after which the information may no longer be valid. Applications must not cache this entity beyond the date given.{2068} A stale cache entry may not normally be returned by a cache (either a proxy cache or an {2616}user agent cache) unless it is first validated with the origin server (or with an intermediate cache that has a fresh copy of the entity). See section 13.2 for further discussion of the expiration model.
Expires 実体頭欄は、
その後はその応答が腐っているとみなす日付・時刻を与えます。 これによって情報提供者が資源の揮発性やそれを過ぎるとその情報がもはや妥当ではなくなるかもしれない日付を提案できます。応用はこの実体を与えられた日付を超えてキャッシュしてはなりません。 腐ったキャッシュ項目は通常は (まず起源サーバー (またはその実体の新鮮な複製を持っている中間キャッシュ) により検証しない限り) キャッシュ (串キャッシュも利用者エージェントキャッシュも。) は返してはいけません。期限切れ模型についての詳しい話題は 13.2 節を参照。
The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after that time.
{1945} However, information providers that know or even suspect that a resource will change by a certain date should include an Expires header with that date.
Expires 欄が示されていることは元の資源がその時刻の時点又は前後に変更されたり消滅したりすることを暗示するものではありません。 しかし、ある日付に資源が変更されることを知っているか、その可能性があると思われる場合でも、情報提供者はその日付を Expires 頭に含めるべきです。
The format is an absolute date and time as defined by HTTP-date in Section 3.3.1 {2616}
. {1945}; it MUST be inRFC1123-date {2068}RFC 1123 date {2616} format: {2068}
- Expires = "Expires" ":" HTTP-date
An example of its use is
- Expires: Thu, 01 Dec 1994 16:00:00 GMT
{2068} Note: if a response includes a Cache-Control field with the max-age directive (see section 14.9.3), that directive overrides the Expires field.
注意 : 応答が Expires 欄を上書きします。
{1945} If the date given is equal to or earlier than the value of the Date header, the recipient must not cache the enclosed entity. If a resource is dynamic by nature, as is the case with many data-producing processes, entities from that resource should be given an appropriate Expires value which reflects that dynamism. The Expires field cannot be used to force a user agent to refresh its display or reload a resource; its semantics apply only to caching mechanisms, and such mechanisms need only check a resource's expiration status when a new request for that resource is initiated.
与えられた日付が Expires
値を与えるべきです。 Expires 欄は利用者エージェントがその表示を再描画したり資源を再読み込みしたりするのを強制するためには使えません。
Expires 欄の意味はキャッシュ機構にのみ適用され、
その機構はその資源に対する新しい要求が初期化されるときに資源の期限切れ状態を検査する必要があるだけです。
User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity retrieved earlier in a session. By default, the Expires field does not apply to history mechanisms. If the entity is still in storage, a history mechanism should display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents.
利用者エージェントはよく「戻る」ボタンや履歴一覧のような履歴機構を持っていて、
セッション中で前に取り出した実体を再表示するのに使うことができます。
既定では、 Expires 欄は履歴機構には適用されません。
実体が依然蓄積装置中にあれば、利用者が期限切れ履歴文書を再描画するようにエージェントをわざわざ設定していない限り、
履歴機構はその実体が期限切れになっていてもそれを表示するべきです。
Note: Applications are encouraged to be tolerant of bad or misinformed implementations of the Expires header. A value of zero (0) or an invalid date format should be considered equivalent to an "expires immediately." Although these values are not legitimate for HTTP/1.0, a robust implementation is always desirable.
注意 : 応用は Expires
頭の悪い間違った実装に慣用であることを推奨します。値零 (0)
や不当な日付書式は「即座に期限切れ」と同等と考えるべきです。
これらの値は HTTP/1.0 的には正しくありませんが、頑強な実装が常に望ましいです。
{2068} HTTP/1.1 clients and caches MUST treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired").
HTTP/1.1 クライアントや HTTP/1.1 キャッシュは、
他の不正な日付書式、特に値 0 を、
過去である (つまり「既に期限切れである」) として扱わなければなりません。
To mark a response as "already expired," an origin server
{2068} should use{2616}] sends an Expires date that is equal to the Date header value. (See the rules for expiration calculations in section 13.2.4.)
応答を「既に期限切れである」としてマークするには、
起源サーバーは Date 頭値と等しい Expires
日付を送ります。 (期限切れ計算規則については 13.2.4 節を参照。)
To mark a response as "never expires," an origin server
{2068} should use{2616} sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers{2068} should not{2616} SHOULD NOT send Expires dates more than one year in the future.
応答を「絶対に期限切れしない」とマークするには、
起源サーバーは応答が送信された時刻からほぼ1年後の Expires
日付を送ります。 HTTP/1.1 サーバーは1年よりも将来の Expires
日付を送るべきではありません。
The presence of an Expires header field with a date value of some time in the future on a
n {2616}response that otherwise would by default be non-cacheable ({2068,2616} ママ) indicates that the response is cacheable, unless indicated otherwise by a Cache-Control header field (section 14.9).
幾らか将来の日付値の Expires 頭欄がそうでなければ既定ではキャッシュ可能ではない応答にあることは、
その応答が
The Expires entity-header field gives a date and time after which the description or media-stream should be considered stale. The interpretation depends on the method:
DESCRIBE response:
The Expires header indicates a date and time after which the description should be considered stale.
A stale cache entry may not normally be returned by a cache (either a proxy cache or an user agent cache) unless it is first validated with the origin server (or with an intermediate cache that has a fresh copy of the entity). See section 13 for further discussion of the expiration model.
The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after that time.
The format is an absolute date and time as defined by HTTP-date in [H3.3]; it MUST be in RFC1123-date format:
HTTP-date
として定義されている絶対日時で、 RFC1123-date
形式でなければなりません。
[5] Expires = "Expires" ":" HTTP-date
An example of its use is
[6] Expires: Thu, 01 Dec 1994 16:00:00 GMT
RTSP/1.0 clients and caches MUST treat other invalid date formats, especially including the value "0", as having occurred in the past (i.e., "already expired").
"0" で過去に起こった (つまり「既に期限切れ」)
を示すものを取り扱えなければなりません。
To mark a response as "already expired," an origin server should use an Expires date that is equal to the Date header value. To mark a response as "never expires," an origin server should use an Expires date approximately one year from the time the response is sent. RTSP/1.0 servers should not send Expires dates more than one year in the future.
The presence of an Expires header field with a date value of some time in the future on a media stream that otherwise would by default be non-cacheable indicates that the media stream is cacheable, unless indicated otherwise by a Cache-Control header field (Section 12.8).
To ensure compatibility with HTTP/1.0 caching proxies which do not recognize the Vary header, an Expires header with a date in the past can be added to the response, for example
- Expires: Thu, 01 Jan 1980 00:00:00 GMT
を加えることが出来ます。
If this is done by an origin server, the server SHOULD usually also include a Cache-Control header for the benefit of HTTP/1.1 caches, for example
- Cache-Control: max-age=604800
which overrides the freshness lifetime of zero seconds specified by the included Expires header.
のような Expires 頭を含めたことによって指定された零秒の
Note: This specification only claims downwards compatibility with the HTTP/1.0 proxy caches which implement the HTTP/1.0 specification [2]. Some legacy proxy caches which return the HTTP/1.0 protocol version number do not honor the HTTP/1.0 Expires header as specified in [2]. Methods for achieving compatibility with such proxy caches are beyond the scope of this specification.
注意 : この仕様書は HTTP/1.0 仕様書を実装する HTTP/1.0
串キャッシュとの後方互換性を主張するだけです。
HTTP/1.0 プロトコル版番号を返す遺産的串キャッシュの中には
Expires
頭を尊重しないものもあります。
そのような串キャッシュとの後方互換性の達成の方法はこの仕様書の適用範囲外です。
obs-Expires とでもして)
入れとけ、と思うな。
<
みたいなふざけたのを平気で人にすすめる様な輩もいる。天罰でも食らえ。
-1 を推奨してます!
それも、 Cache-Control: no-cache よりも
Expires: -1 の方が望ましいのとか(w :
Q234067 - HOWTO: Prevent Caching in Internet Explorer
なんて無根拠の嘘八百を平気で教えている糞解説サイトがあります。
騙されないように!Expires には
2007-07-28 14:53:07 +09:00 版)
Expires: -1
(
2007-08-02 21:41:54 +09:00 版)
<META HTTP-EQUIV="Expires" content="Sun,6 Jun 2006 00:00:00 GMT">
Expires を 1 週間以上、できれば最大で 1 年間先に設定します(より広くサポートされているため、Cache-Control: max-age よりも Expires をおすすめします)。RFC のガイドラインに違反するので、1 年以上先には設定しないでください。