364.txt

* Expires: 欄 (電子ニュース, HTTP, RTSP)

** 仕様書から


*** 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 の空きに基づく。) 
があるので、利用者は話題に関する自然な期限切れ日があるのではない限り、期限切れ日を指定するのは避けるのがよいです。
処理系ソフトウェアは既定の [CODE(ABNF)["Expires"]] (期限切れ)
行をほとんど絶対に用意しておかないのが良いです。
この行を適切な理由が無い限り使わずに、 local の方針が使われるようにして下さい。


*** RFC 1945 (HTTP/1.0) 10.7; RFC 2068 (HTTP/1.1) 14.21 Expires

[INS[

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

> The Expires entity-header field gives the date/time after which 
the [DEL[[INS[{1945}]] entity]] [INS[[INS[{2068}]] response]] [DEL[[INS[{2068}]] should be]] [INS[[INS[{2616}]] is]] considered stale. [DEL[[INS[{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.]] [INS[[INS[{2068}]] A stale cache entry may not normally be returned by a cache (either a proxy cache or a[DEL[n [INS[{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.]]

[CODE(HTTP)[Expires]] 実体頭欄は、
その後はその応答が腐っているとみなす日付・時刻を与えます。 [DEL[これによって情報提供者が資源の揮発性やそれを過ぎるとその情報がもはや妥当ではなくなるかもしれない日付を提案できます。応用はこの実体を与えられた日付を超えてキャッシュしてはなりません。]] [INS[腐ったキャッシュ項目は通常は (まず起源サーバー (またはその実体の新鮮な複製を持っている中間キャッシュ) により検証しない限り) キャッシュ (串キャッシュも利用者エージェントキャッシュも。) は返してはいけません。期限切れ模型についての詳しい話題は 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. [DEL[[INS[{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.]]

[CODE(HTTP)[Expires]] 欄が示されていることは元の資源がその時刻の時点又は前後に変更されたり消滅したりすることを暗示するものではありません。 [DEL[しかし、ある日付に資源が変更されることを知っているか、その可能性があると思われる場合でも、情報提供者はその日付を [CODE(HTTP)[Expires]] 頭に含めるべきです。]]

> The format is an absolute date and time as defined by HTTP-date in Section 3.3[INS[.1 [INS[{2616}]]]][DEL[. [INS[{1945}]]]][INS[; it MUST be in [DEL[RFC1123-date [INS[{2068}]]]] [INS[RFC 1123 date [INS[{2616}]]]] format: [INS[{2068}]]]]
>
- Expires = "Expires" ":" HTTP-date

> An example of its use is

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

[INS[

> [INS[{2068}]] Note: if a response includes a Cache-Control field with the max-age
directive [INS[(see section 14.9.3)]], that directive overrides the Expires field.

注意 : 応答が [CODE(HTTP)[[[max-age]]]] 指令つきの [CODE(HTTP)[[[Cache-Control]]]] 欄を含んでいる時は、その指令が [CODE(HTTP)[Expires]] 欄を上書きします。
]INS]

[DEL[

> [INS[{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.

与えられた日付が [CODE(HTTP)[[[Date]]]] 頭の値と等しいか、又はそれ以前であるときは、
受信者は囲まれた実体をキャッシュしてはなりません。
多くのデータ生産過程の場合のように資源が本質的に動的なものであるなら、
その資源からの実体はその動的性を反映した適切な [CODE(HTTP)[Expires]]
値を与えるべきです。 [CODE(HTTP)[Expires]] 欄は利用者エージェントがその表示を再描画したり資源を再読み込みしたりするのを強制するためには使えません。
[CODE(HTTP)[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.

利用者エージェントはよく「戻る」ボタンや履歴一覧のような履歴機構を持っていて、
セッション中で前に取り出した実体を再表示するのに使うことができます。
既定では、 [CODE(HTTP)[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.

注意 : 応用は [CODE(HTTP)[Expires]] 
頭の悪い間違った実装に慣用であることを推奨します。値零 ([CODE(HTTP)[0]])
や不当な日付書式は「即座に期限切れ」と同等と考えるべきです。
これらの値は HTTP/1.0 的には正しくありませんが、頑強な実装が常に望ましいです。
]DEL]

[INS[

> [INS[{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 キャッシュは、
他の不正な日付書式、特に値 [CODE(HTTP)[0]] を、
過去である (つまり「既に期限切れである」) として扱わなければ'''なりません'''。

> To mark a response as "already expired," an origin server [DEL[[INS[{2068}]] should use]] [INS[[INS[{2616}]]] sends]]
an Expires date that is equal to the Date header value. (See the
rules for expiration calculations in section 13.2.4.)

応答を「既に期限切れである」としてマークするには、
起源サーバーは [CODE(HTTP)[Date]] 頭値と等しい [CODE(HTTP)[Expires]]
日付を送ります。 (期限切れ計算規則については 13.2.4 節を参照。)

> To mark a response as "never expires," an origin server [DEL[[INS[{2068}]] should use]] [INS[[INS[{2616}]] sends]] an
Expires date approximately one year from the time the response is
sent.  HTTP/1.1 servers [DEL[[INS[{2068}]] should not]] [INS[[INS[{2616}]] SHOULD NOT]] send Expires dates more than one
year in the future.

応答を「絶対に期限切れしない」とマークするには、
起源サーバーは応答が送信された時刻からほぼ1年後の [CODE(HTTP)[Expires]]
日付を送ります。 HTTP/1.1 サーバーは1年よりも将来の [CODE(HTTP)[Expires]]
日付を送る'''べきではありません'''。

> The presence of an Expires header field with a date value of some
time in the future on a[DEL[n [INS[{2616}]]]] response that otherwise would by default be
non-cacheable [INS[({2068,2616} ママ)]] indicates that the response is cach[INS[e]]able, unless
indicated otherwise by a Cache-Control header field (section 14.9).

幾らか将来の日付値の [CODE(HTTP)[Expires]] 頭欄がそうでなければ既定ではキャッシュ可能ではない応答にあることは、
その応答が [CODE(HTTP)[[[Cache-Control]]]] 頭欄で別途示されていない限り、
その応答がキャッシュ可能であることを示します。
]INS]


*** 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] で [CODE(ABNF)[HTTP-date]] 
として定義されている絶対日時で、 [CODE(ABNF)[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 クライアント及びキャッシュは他の不正な日付形式,
特に値 [CODE(ABNF)["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
頭欄で別段の指定がない限りはキャッシュ可能であることを示します。


*** 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

[CODE(HTTP)[[[Vary]]]] 頭を認識しない HTTP/1.0 
[[キャッシュ串]]との互換性を確保するため、
応答に過去の日付の [CODE(HTTP)[[[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.

のような [CODE(HTTP)[[[Cache-Control]]]] 頭をも含めて、
[CODE(HTTP)[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 [CODE(HTTP)[Expires]] 
頭を尊重しないものもあります。
そのような串キャッシュとの後方互換性の達成の方法はこの仕様書の適用範囲外です。


** メモ

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

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

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

[16] >>14-15 実はなんと [[M$]] が [CODE(HTTP)[-1]] を推奨してます! 
それも、 [CODE(HTTP)[Cache-Control: no-cache]] よりも 
[CODE(HTTP)[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] 
[Q[[CODE(HTTP)[[[Date]]]] は [[RFC 1123の日付形式]]だけど [CODE(HTTP)[Expires]] には [[RFC 850の日付形式]]を使います]]
なんて無根拠の嘘八百を平気で教えている糞解説サイトがあります。
騙されないように!

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

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

>
[PRE(HTTP example bad code)[
Expires: -1
]PRE]

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

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

>
[PRE(HTML example code)[
<META HTTP-EQUIV="Expires" content="Sun,6 Jun 2006 00:00:00 GMT">
]PRE]

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

[[#comment]]


* RFC の部分の License

[[RFCのライセンス]]


* メモ

[20] [CITE[Apache HTTP Server Project]]
( ([TIME[2011-05-28 00:58:55 +09:00]] 版))
<http://httpd.apache.org/docs/1.3/misc/known_client_problems.html#msie-cookie-y2k>

[21] [CITE@ja[cookieのexpireがブラウザにより異なる - 昼間のメモ]]
( ([TIME[2012-06-20 01:48:16 +09:00]] 版))
<http://blog.goo.ne.jp/hiuchida/e/1da4b676a699206c7e26e7b5edee1443>

[22] [CITE@Ja[cookieの書式 / ''''''[''''''network'''''']'''''''''['''HTTP''']''' | 戯術者の日記]]
( ([TIME[2012-06-20 01:50:39 +09:00]] 版))
<http://www.jp-z.jp/changelog/2004-11-12-2.html>

[23] [CITE@en[Leverage Browser Caching - PageSpeed Insights — Google Developers]]
( ([TIME[2013-07-22 23:43:00 +09:00]] 版))
<https://developers.google.com/speed/docs/insights/LeverageBrowserCaching>