[5] Date: ヘッダーは、
メッセージの生成時刻を表します。
[506] HTTP の Date: ヘッダーは、
メッセージが元々作成された日時を表します >>505。
[510] HTTP Date: ヘッダーを生成するときは、
メッセージの生成の日時を最大限近似した値を生成するべきです。
理論上は payload の生成の直前の瞬間を表すべきです。
実際上はメッセージの作成中のいつの時刻でもあり得ます。 >>505
[511] HTTP 起源サーバーは、生成の瞬間の UTC
の適当な近似を得る能力を持った時計を有しない時は、
Date: ヘッダーを送信してはなりません >>505。
[512] HTTP 起源鯖は、 1xx と 5xx
の応答で Date: を生成しても構いません >>505。
[513] HTTP 起源鯖はその他の場合に Date: ヘッダーを送信しなければなりません
>>505。
[515] HTTP 利用者エージェントは、要求で Date:
ヘッダーを送信しても構いません。ただし鯖にとって有用であると信ずる場合以外は普通は送信しません。
>>505
[517] 電子メールもHTTP も歴史的に同じ Date:
ヘッダーから出発していますが、その後のそれぞれの仕様の改訂により現在は異なる構文となっています。
[11] 非妥当な値の処理については、 HTTP-date
を参照。
[514] 時計を有する HTTP 受信者は、
応答メッセージをキャッシュしたり下流に転送したりする場合、
Date: ヘッダーが含まれていなければ、
受信した時刻を記録し、 Date: ヘッダーを付加しなければなりません
>>505。
[3] MSA は、メッセージに
Date: 欄が欠けている場合、
これを追加して構いません。
また、 Date: 欄の書式が
RFC 2822 に適合しない場合、これを修正して構いません。
RFC 4409 8.2
[1] [HTTP92] (Object Header lines in HTTP http://www.w3.org/Protocols/HTTP/Object_Headers.html#date) では Date: 欄の値は物体が作成された時間を指定するとされていました。原案ですが。
[2] >>1 この機能を持った欄は今の HTTP にはありませんね。 MIME の Content-Disposition: disposition; creation-date=date を使うという方法はあります。
The Date general-header field represents the date and time at which the message was originated, having the same semantics as orig-date in RFC 822. The field value is an HTTP-date, as described in
{1945} Section 3.3{2068} section 3.3.1; it MUST be sent in RFC 1123 [8]-date format {2616}.
Date 一般頭欄は、メッセージが起源された日時を表現します。
これは RFC822 の orig-date と同じ意味を持ちます。
欄値は HTTP-date です。
欄値は RFC 1123 日付書式で送信しなければなりません。
- Date = "Date" ":" HTTP-date
An example is
- Date: Tue, 15 Nov 1994 08:12:31 GMT
{2616} Origin servers MUST include a Date header field in all responses, except in these cases:
起源サーバーは、次の場合を除いて全ての応答に Date
頭欄を含めなければなりません。
- 1. If the response status code is 100 (Continue) or 101 (Switching Protocols), the response MAY include a Date header field, at the server's option.
- 2. If the response status code conveys a server error, e.g. 500 (Internal Server Error) or 503 (Service Unavailable), and it is inconvenient or impossible to generate a valid Date.
- 3. If the server does not have a clock that can provide a reasonable approximation of the current time, its responses MUST NOT include a Date header field. In this case, the rules in section 14.18.1 MUST be followed.
100 (継続) 又は
101 (プロトコル切り替え) であれば、応答はサーバーの任意選択によって、
Date 頭欄を含んでもかまいません。500
(サーバー内部誤り) や 503 (サービス利用不可能)
の場合で、妥当な Date を生成するのか不便又は不可能な場合。Date 頭欄を含んでいてはなりません。
この場合、 14.18.1 節の規則に従わなければなりません。{1945,2068} If a message is received via direct connection with the user agent (in the case of requests) or the origin server (in the case of responses), then the date can be assumed to be the current date at the receiving end. However, since the date--as it is believed by the origin--is important for evaluating cached responses, origin servers
{1945} should always{2068} MUST include a Date header {2068} field in all responses. Clients{1945} should{2068} SHOULD only send a Date header field in messages that include an{1945} entity body{2068} entity-body, as in the case of the {2068} PUT and POST requests {2068}, and even then it is optional. A received message which does not have a Date header field{1945} should{2068} SHOULD be assigned one by the recipient if the message will be cached by that recipient or gatewayed via a protocol which requires a Date.
メッセージが (要求の場合) 利用者エージェント又は起源サーバー (応答の場合)
との直接接続により受信したものであれば、日付は受信末端の現在日付と仮定できます。
しかし、日付 —であると起源が信じているもの—はキャッシュ応答の評価に重要ですから、
起源サーバーは全ての応答中に Date 頭を含めるべきですなければなりません。
クライアントは、 PUT 要求及び POST 要求で
entity-body を含んでいるメッセージにのみ
Date 頭欄を送るべきです。もっとも省略可能ではありますが。
受信したメッセージが Date 頭欄を持たなければ、
メッセージがその受信者にキャッシュされるか又は Date
を必須とするプロトコルに関門されるときには、受信者がこれを割当てるべきです。
{2616} A received message that does not have a Date header field MUST be assigned one by the recipient if the message will be cached by that recipient or gatewayed via a protocol which requires a Date. An HTTP implementation without a clock MUST NOT cache responses without revalidating them on every use. An HTTP cache, especially a shared cache, SHOULD use a mechanism, such as NTP [28], to synchronize its clock with a reliable external standard.
受信したメッセージが Date 頭欄を持たないとき、
そのメッセージが受信者の一人によりキャッシュされるか又は Date
を必須とするプロトコルに関門するなら、
その受信者は日付を割り当てなければなりません。
時計を持たない HTTP 実装は、使用時毎に再検証することなしに応答をキャッシュしてはなりません。
HTTP キャッシュ, 特に共有キャッシュは、 NTP のような時計を信頼できる外部規格により同期する機構を使用するべきです。
Clients SHOULD only send a Date header field in messages that include an entity-body, as in the case of the PUT and POST requests, and even then it is optional. A client without a clock MUST NOT send a Date header field in a request.
クライアントは、 PUT 要求や POST 要求の場合で
entity-body を含んでいるメッセージにのみ
Date 頭欄を送るべきです。もっとも、その場合でも省略可能ではあります。
時計を持たないクライアントは Date 頭欄を要求で送ってはなりません。
{2616} The HTTP-date sent in a Date header SHOULD NOT represent a date and time subsequent to the generation of the message. It SHOULD represent the best available approximation of the date and time of message generation, unless the implementation has no means of generating a reasonably accurate date and time. In theory, the date
{2616} ought to represent the moment just before the entity is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic value.{1945} should{2068} SHOULD
Date 頭で送信される HTTP-Date
はメッセージの生成の後の日時を表現するべきではありません。
HTTP-Date は、その実装に適度に正確な日時を生成する手段がない場合を除いて、
メッセージ生成日時の最善の近似を表現するべきです。
理論上は、日付は実体が生成される直前の瞬間を表現するべきです。
実際上は、その意味的値に影響しない範囲でメッセージ生成中の何時でも生成できます。
{1945} Note: An earlier version of this document incorrectly specified that this field should contain the creation date of the enclosed Entity-Body. This has been changed to reflect actual (and proper) usage.
注意 : この文書の初期の版では、この欄は囲まれた実体本体の生成日付を含めるべきであると間違って規定していました。 これは実際の (適切な) 用法を反映するように改めました。
{2068} The format of the Date is an absolute date and time as defined by HTTP-date in section 3.3; it MUST be sent in RFC1123 [8]-date format.
Date の書式は絶対日時です。 RFC 1123 の日付書式で送らなければなりません。
Some origin server implementations might not have a clock available. An origin server without a clock MUST NOT assign Expires or Last-Modified values to a response, unless these values were associated with the resource by a system or user with a reliable clock. It MAY assign an Expires value that is known, at or before server configuration time, to be in the past (this allows "pre-expiration" of responses without storing separate Expires values for each resource).
利用出来る時計を持たない起源サーバー実装もあります。
時計のない起源サーバーは、信頼できる時計のシステム又は利用者によりその資源に関連付けられた値でない限り、
応答に Expire や
Last-Modified の値を設定してはなりません。
時計のない起源サーバーは、サーバー設定時またはそれ以前に過去であることが分かっている
Expire 値を割り当てても構いません
(これによって各資源それぞれの Expire 値を蓄積することなしに
「事前期限切れ」が実現できます)。
[518] Last-Modified: ヘッダーは payload
の更新日時を表しています。通常は Date: より前になります。
Date: Tue, 15 Nov 1994 08:12:31 GMT
Date: 10.7.2014
[18] ようこそ - 天童市オープンデータ, https://data.city.tendo.yamagata.jp/
Date: Sun, 19 May 2024 16:01:27 GMT
[19] >>18 9時間と2分ほど本来の日時より進んでいます。9時間ずれているのは日本中央標準時 () の数値をUTCの数値と誤って時計が設定されていることによると推測され、 2分ずれているのはシステム時計が適切に同期されずずれたまま稼働していると推測されます。
Date に全然触れてないじゃん。。。他に適当な場所がないからかな。Date 頭の日付の途中で折畳みされていると正しく日付を扱えない MUA があります。日付の途中で fold しないのが賢明です。[504] Twiggy という Perl のWebサーバーは Date: を送信しないようです。
[520] RFC 5536 - Netnews Article Format ( ( 版)) http://tools.ietf.org/html/rfc5536#section-3.1.1
To create the X-Amzn-Authorization header
Create a Date header to be used in the request. For more information, go to http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.18.
Date:ヘッダーと同じです >>505。