[6] Last-Modified:
ヘッダーは、
応答に含まれる表現の最終変更日時を表します。
[9] Last-Modified:
ヘッダーは、
起源鯖が要求の処理の完了の時点において選択された表現が最後に変更されたと信ずる日時を表します
>>5。
[47] 何をもって最終変更日時とするかは著者の判断に委ねられるところであり、
意味的には若干の曖昧性があります。ファイルシステム上のファイルを応答として使う
(静的ファイルを提供する) サーバーでは、ファイルシステム上の更新日時を使うのが普通です。
しかし動的に生成される場合、複数の情報源 (データベース等) のデータを組み合わせて応答を作成することが多く、
何をもって最終変更日時とするべきかは定かではありません。その応答の作成の時刻
(つまり Date:
と同じ時刻) かもしれませんが、
それならそれを明示しても意味が無い場合もあるかもしれません。
[48] 例えばファイルシステム上のファイルに広告を差し込んで応答とする場合は、 ファイルシステム上のファイルの更新日時を使うべきで、差し込んだ日時を使うべきではないかもしれません。 しかし著者がその広告が当該ページの重要なコンテンツを形成するとみなすなら、 ファイルと広告の新しい方の日時を使うべきかもしれません。
[49] 何が最終変更日時か著者にとっても明確でない時や、
Date:
と同じにするしかなく、それには意味が無いと著者が考えるときは、
省略するべきでしょう。本ヘッダーは必須ではありません。
[50] 例えばデータベースから無作為に選択した内容を表示するときは、 本ヘッダーは省略した方が良いかもしれません。
[10] Last-Modified:
ヘッダーの値は、
HTTP-date
です >>5。
[12] 起源鯖は、選択された表現の最終修正日時が合理的かつ一貫的に決定できるなら、
Last-Modified:
を送信するべきです >>5。
その値はできるだけ応答の Date:
ヘッダーを生成する時刻の近くの時点で得るべきです
>>5。
[13] 表現はいくつかの部分を組み合わせて構成されることがよくありますが、 その場合それらのうちで最も直近に変更されたものの日時が最終修正日時となるのが普通です。 >>5
[14] 時計を持つ起源鯖は、 Date:
より後の
Last-Modified:
を送信してはなりません >>5。
メタデータによると鯖の時計よりも後の最終修正日時となるような場合には、
Date:
の値で置き換えなければなりません >>5。
[16] 時計を持たない起源鯖は、他の信頼できる時計を持つシステムや利用者が指定している場合を除き、
Last-Modified:
を設定してはなりません >>5。
[32] WebDAV 鯖は資源の本体や URL が変わっていないならタイムスタンプを変えるべきではありません >>31。
[34] WebDAV 鯖は、 (COPY
や MOVE
などの URL を操作するメソッドの結果であろうと、) GET
が返すであろうものが変わる度にタイムスタンプを (その精度内で)
変更しなければなりません。 >>33
[17] Last-Modified:
ヘッダーの値が強い検証子か弱い検証子かは、
次のように決定できます >>5。
Last-Modified:
の値だったとすると、
少なくても一方の Date:
は Last-Modified:
と一致するはず、という性質によっています。60秒としているのは Date:
と Last-Modified:
が異なる時計から得られた場合などを想定しており、
短すぎると考えるならより長くとっても構いません。 >>5[30] Last-Modified:
ヘッダーはキャッシュにおける発見的満期時刻の決定にも用いられます。
DAV:getlastmodified
特性 (WebDAV)[39] DAV:getlastmodified
特性は、
accept header なしで GET
した場合に返されるであろう
Last-Modified:
ヘッダーの値を表します >>38。
[40] 値は HTTPの日時形式です >>38。 OWS がヘッダーに含まれる場合でも、 値には含めるべきではありません >>37。
[41] 保護特性であるべきです >>38。
これはキャッシュの適切な動作や Last-Modified
の値に依存するクライアントがあるかもしれないからです >>38。
[42] COPY
や MOVE
の後の値は、
終点資源の最終修正日時により決まります。 >>38
[43] しかし実装によっては HTTP Last-Modified:
の値が変わるべき時であっても、ファイルシステムの日時を使っているため、
変化しないこともあります >>38。
[44] Last-Modified
は、本体の変更のみを反映するべきであり、
特性のみの変更では変更するべきではありません >>38。
これはクライアントが既存の本体を上書きするべきかどうかの判断に
Last-Modified
を使うことがあるからです >>38。
[45] WebDAV に従う資源が GET
への応答で
Last-Modified:
ヘッダーを返す場合は、
DAV:getlastmodified
特性を定義しなければなりません
>>38。
[2] Last-Modified:
欄は HTTP では実体頭欄に分類されています。
ですから、要求でも応答でも、そのメッセージが
(HEAD
のように一部省略されている場合も含めて)
実体を含んでいるのなら使えるように思えます。
しかし、 RFC 1945 で sender
とされていたところが、わざわざ RFC 2068 以後は
origin server
に直されていて、
要求で使えるような気配がまったくありません。
[3] PUT
や POST
で実体を鯖に送る時には使えないのでしょうか。
(Content-Disposition
でも使えというのでしょうか?)
[4] HTML5 IRC logs: freenode / #whatwg / 20070626 ( 版) <http://krijnhoetmer.nl/irc-logs/whatwg/20070626#l-151> (名無しさん 2007-06-26 13:17:00 +00:00)
[23] ファイルシステムから静的にデータを供給する鯖では、
ファイルシステムの最終修正日時を Last-Modified:
に設定するのが普通です。
[24] 鯖で動的に生成した内容を返す場合には、生成する内容の種類や情報源により、
また実装に用いられているプログラミング言語やフレームワークにもよりますが、
Last-Modified:
が指定されていることはそれほど多くはありません。
そのためWebブラウザーのキャッシュが有効に作用するであろう場面でも、
毎回鯖へのアクセスが発生することがよくあります。
[46] Apache は CGIスクリプトか指定した値を再整形して応答として使います。 そのため、CGIスクリプトの中には、曜日を適当に指定するなど、 Apache の再整形を期待して適当な出力をするものもあるようです。
[25] DOM では Document
オブジェクトに
lastModified
IDL属性があり、
HTTP Last-Modified:
ヘッダーの値にアクセスできます。