Expires

Expires: ヘッダー (HTTP)

[44] Expires: ヘッダー応答腐敗する日時を指定します。

仕様書

意味

[29] Expires: ヘッダーは、 それ以後応答腐敗と考えるべき日時を指定するものです >>28

[30] なお、 Expires: ヘッダーがあるからといって、 その時刻の前後に対象資源が変化したり、消滅したりするとは限りません >>28

[43] また、このヘッダーを指定したとしても、キャッシュがその時刻まで応答蓄積し続けることは保証されません。キャッシュはいつでも蓄積された応答を破棄できます。

[45] 逆にキャッシュ蓄積された応答を破棄することも保証されません。 キャッシュは指定された日時に至った後も、検証することで腐敗応答再利用できます。

構文

[32] Expires: ヘッダーの値は、 HTTP-date です >>28

  1. HTTPの日時形式

文脈

[11] 304 の項も参照。

[40] 時計を持たない起源鯖は、過去の固定の日時を指定する場合か、 信頼できる時計を持ったシステムや利用者が設定した日時である場合を除き、 Expires: ヘッダー生成してはなりません >>28

Expires:Cache-Control: max-age との併用

[49] HTTP/1.0 キャッシュさせず、比較的新しいにのみキャッシュを許すため、 Expires:キャッシュされないような日付を指定し、 Cache-Control: max-ageキャッシュされるような値を指定する技法が使われることがありました >>17, >>19, >>48, >>50

[47] 選択応答では HTTP/1.0 キャッシュキャッシュさせないために Expires: ヘッダーを含めることが認められています >>46, >>48

[51] 起源鯖Ext:生成する場合、 要求プロトコルの版Via: から HTTP/1.0 中間器により転送されたことが分かれば、 Date: と同じかそれよりも前の Expires: を指定しなければなりません >>50

[53] なお RFC 3329 はこの方法がすべての HTTP/1.0 に有効か疑問であるとして、 かわりに新しい状態符号を導入する方法を採っています >>52

処理モデル

[25] Expires: ヘッダーの有無は応答キャッシュ蓄積できるかに影響します。

詳しくはキャッシュ可能性を参照。

[27] Expires: ヘッダーの値は新鮮寿命の計算に影響します。

詳しくは新鮮寿命を参照。

[31] キャッシュである受信者は、 HTTP-date より扱える時刻の精度が低い場合、指定された時刻と同じかそれより前の直近の時刻を内部的に用いるべきです >>26

[34] キャッシュである受信者は、「0」を含む構文的に正しくない値を過去の日付が指定されたものと解釈しなければなりません >>28

[33] 複数ヘッダーがある場合については、新鮮寿命を参照。

歴史

ネットニュース

[35] RFC 1036 2.2.4. Expires

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.

[12] この行は、これを使う場合、妥当な USENET 日付形式で書きます。 そのメッセージの期限切れ日として希望する日を指定します。 この行が無い場合は、 local の既定の期限切れ日が使われます。 この欄は限定的に有用なメッセージを消去したり、重要なメッセージを普通より長めに残しておくのに使われます。 例えば、近日行われる講習会のお知らせメッセージは講習会が過ぎれば有用ではないので、講習会の次の日を期限とすることが出来ます。 Local ホストはニュースの期限に関して local の方針 (例えば利用可能な disk の空きに基づく。) があるので、利用者は話題に関する自然な期限切れ日があるのではない限り、期限切れ日を指定するのは避けるのがよいです。 処理系ソフトウェアは既定の "Expires" (期限切れ) 行をほとんど絶対に用意しておかないのが良いです。 この行を適切な理由が無い限り使わずに、 local の方針が使われるようにして下さい。

HTTP

[36] RFC 1945 (HTTP/1.0) 10.7; RFC 2068 (HTTP/1.1) 14.21 Expires

編注 : RFC 1945 の段落は HTTP/1.1 RFC にあわせて適当にぶったぎってます。

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 in RFC1123-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.

注意 : 応答が max-age 指令つきの Cache-Control 欄を含んでいる時は、その指令が 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.

与えられた日付が Date 頭の値と等しいか、又はそれ以前であるときは、 受信者は囲まれた実体をキャッシュしてはなりません。 多くのデータ生産過程の場合のように資源が本質的に動的なものであるなら、 その資源からの実体はその動的性を反映した適切な 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 an {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 頭欄がそうでなければ既定ではキャッシュ可能ではない応答にあることは、 その応答が Cache-Control 頭欄で別途示されていない限り、 その応答がキャッシュ可能であることを示します。

[37] RFC 2326 (RTSP/1.0) 12.19 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:

[1] Expires 実体頭欄は、記述又は媒体 stream が腐ったと見なすのが良い日付と時刻を指定します。 解釈は方式に依存します。

DESCRIBE response:

The Expires header indicates a date and time after which the description should be considered stale.

DESCRIBE 応答
Expires 頭欄は、これを過ぎたら記述が腐ったと見なすのがよい日付と時刻を示します。

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.

[2] 腐ったキャッシュ項目は通常キャッシュ (串キャッシュであれ利用者エージェント・キャッシュであれ) から返してはいけません。但し初めに元サーバー (又は実体の新鮮な複製を持つ中間キャッシュ) に確認した場合を除きます。期限切れモデルの詳しい話は13章を参照して下さい。

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.

[3] Expires 欄が存在することは、その時刻の前後において元資源が変更されたり存在しなくなったりすることを強制するものではありません。

The format is an absolute date and time as defined by HTTP-date in [H3.3]; it MUST be in RFC1123-date format:

[4] 書式は [H3.3] で 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").

[7] RTSP/1.0 クライアント及びキャッシュは他の不正な日付形式, 特に値 "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.

[8] 「既に期限切れ」と応答に記すのに、元サーバーは Date 頭の値と等しい Expires 日付を使うのが良いです。 応答を「絶対期限切れしない」と記すのに、元サーバーは Expires 日付を応答が送られた時刻から大体1年後にするのが良いです。 RTSP/1.0 サーバーは1年以上将来の Expires 日付を送らないのが良いです。

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).

[9] 将来のいつかの時刻値が入った Expires 頭欄が、これが存在しなければ既定ではキャッシュ不能である媒体 stream に存在すれば、この媒体 stream は Cache-Control 頭欄で別段の指定がない限りはキャッシュ可能であることを示します。

[38] RFC 2295 (HTTP 透過内容折衝) 10.7 Adding an Expires header for HTTP/1.0 compatibility

[13]

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

Vary 頭を認識しない HTTP/1.0 キャッシュ串との互換性を確保するため、 応答に過去の日付の Expires 頭、例えば

  • 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

起点鯖がこれを行う場合は、鯖は通常 HTTP/1.1 キャッシュの便宜から、例えば

  • Cache-Control: max-age=604800

which overrides the freshness lifetime of zero seconds specified by the included Expires header.

のような Cache-Control 頭をも含めて、 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 プロトコル版番号を返す遺産的串キャッシュの中には RFC 1945 で規定されている HTTP/1.0 Expires 頭を尊重しないものもあります。 そのような串キャッシュとの後方互換性の達成の方法はこの仕様書の適用範囲外です。

[41] かつては Expires: ヘッダーの値は1年以内であることが求められていましたが、 RFC 7234 では撤廃されています >>28

[42] 実際には以前から1年より先の日付、例えば2033年などが指定されることはよくありました。

関連

[39] Cache-Control: ヘッダーmax-age キャッシュ指令s-maxage キャッシュ指令がある場合、 そちらが優先します >>28

満期時刻を参照。

メモ

[10] >>7 なら仕様に (obs-Expires とでもして) 入れとけ、と思うな。

[14] <meta http-equiv="Expires" content="-1"> みたいなふざけたのを平気で人にすすめる様な輩もいる。天罰でも食らえ。

[15] >>10 たぶん >>7 で言いたいことのポイントって、 「不正な形式は期限切れとみなせ」だと思う。 >>14 みたいな阿呆も救済したれと。

[16] >>14-15 実はなんと M$-1 を推奨してます! それも、 Cache-Control: no-cache よりも Expires: -1 の方が望ましいのとか(w : Q234067 - HOWTO: Prevent Caching in Internet Explorer <http://web.archive.org/web/20010810040821/support.microsoft.com/support/kb/articles/Q234/0/67.ASP>

[17] DateRFC 1123の日付形式だけど Expires には RFC 850の日付形式を使います なんて無根拠の嘘八百を平気で教えている糞解説サイトがあります。 騙されないように!

HTTP は常に RFC 1123 を基にした形式を推奨しています。 詳しくは HTTPの日付形式を参照してください。

[18] iGoogle (2007-07-28 14:53:07 +09:00 版) <http://www.google.co.jp/ig?hl=ja>

Expires: -1

(名無しさん 2007-07-28 05:57:16 +00:00)

[19] DUOGATE デュオゲート - 地図・乗換 (2007-08-02 21:41:54 +09:00 版) <http://eznavi.duogate.jp/map/?ctl=8121&box=off>

<META HTTP-EQUIV="Expires" content="Sun,6 Jun 2006 00:00:00 GMT">

読点のあとに空白がない例は珍しいかなと思いまして。 (名無しさん)

[20] Apache HTTP Server Project ( ( 版)) <http://httpd.apache.org/docs/1.3/misc/known_client_problems.html#msie-cookie-y2k>

[21] cookieのexpireがブラウザにより異なる - 昼間のメモ ( ( 版)) <http://blog.goo.ne.jp/hiuchida/e/1da4b676a699206c7e26e7b5edee1443>

[22] cookieの書式 / [network][HTTP] | 戯術者の日記 ( ( 版)) <http://www.jp-z.jp/changelog/2004-11-12-2.html>

[23] Leverage Browser Caching - PageSpeed Insights — Google Developers ( ( 版)) <https://developers.google.com/speed/docs/insights/LeverageBrowserCaching>

[24] RFC 3507 - Internet Content Adaptation Protocol (ICAP) ( ( 版)) <http://tools.ietf.org/html/rfc3507#section-4.3.1>

[305] [HOWTO] Internet Explorer でキャッシュを無効にする ( ( 版)) <http://support.microsoft.com/kb/234067>

[306] RFC 5536 - Netnews Article Format ( ( 版)) <http://tools.ietf.org/html/rfc5536#section-3.2.5>

[54] ブラウザのキャッシュを活用する  |  PageSpeed Insights  |  Google Developers () <https://developers.google.com/speed/docs/insights/LeverageBrowserCaching>

Expires を 1 週間以上、できれば最大で 1 年間先に設定します(より広くサポートされているため、Cache-Control: max-age よりも Expires をおすすめします)。RFC のガイドラインに違反するので、1 年以上先には設定しないでください。