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 の方針が使われるようにして下さい。

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

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 頭欄で別段の指定がない限りはキャッシュ可能であることを示します。

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