If-Unmodified-Since

使い方

クライアントは、他者が行った変更を上書きしてしまわないよう守るために If-Unmodified-Since を含めます。最も一般的なシナリオは HTTP の PUT または DELETE リクエストで、クライアントがリソースは以前に観測した状態のままであると確信したい場合です。ヘッダーに記した日付より後に別のクライアントがリソースを変更していた場合、サーバーは 412 Precondition Failed でリクエストを拒否します。

これは更新の喪失（lost update）問題への対処です。2 つのクライアントが同じリソースを取得し、どちらも編集を行い、どちらも更新を送信します。前提条件がなければ、2 番目の更新が 1 番目を黙って上書きしてしまいます。2 番目のリクエストに If-Unmodified-Since を加えることで、サーバーが競合を検出できるようになります。

ヘッダーの値には HTTP の日付形式を使います。サーバーはこの日付をリソースの Last-Modified タイムスタンプと比較します。リソースの更新日時が If-Unmodified-Since の値と等しいかそれより前であれば、条件は成立し、サーバーは処理を続行します。

より強い一貫性の保証が必要な場合は、ETag 値を用いる If-Match を優先してください。ETag はバイトレベルの精度を提供するのに対し、日付ベースの条件は 1 秒の分解能しかありません。

HTTP-date

値は IMF-fixdate 形式に従います。この日付は、リソースにとって許容される最新の更新時刻を表します。

If-Unmodified-Since: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT

例

クライアントが 2025 年 2 月 15 日にドキュメントを取得し、ここで更新を送信します。If-Unmodified-Since の値は、最初のレスポンスで受け取った Last-Modified の日付と一致しています。このタイムスタンプより後にドキュメントが変更されていた場合、サーバーは 412 Precondition Failed で応答します。

PUT /docs/report.json HTTP/1.1
Host: api.example.re
Content-Type: application/json
If-Unmodified-Since: Sat, 15 Feb 2025 10:30:00 GMT

部分アップロードのための範囲リクエストと組み合わせると、If-Unmodified-Since はチャンクの間に基となるリソースが変更されていないことを保証します。

PATCH /files/dataset.csv HTTP/1.1
Host: api.example.re
If-Unmodified-Since: Fri, 14 Feb 2025 08:00:00 GMT
Content-Range: bytes 0-1023/4096