HTTPヘッダーにおけるTimestamp

HTTPは、キャッシュ制御、条件付きリクエスト、コンテンツの鮮度管理のために、いくつかのヘッダーでtimestampを使用しています。これらのヘッダーの理解は、パフォーマンスの高いWebアプリケーションとAPIの構築に不可欠です。

主要なtimestampヘッダー：

Date: Mon, 15 Jan 2024 09:30:00 GMT
Last-Modified: Sun, 14 Jan 2024 20:00:00 GMT
Expires: Tue, 16 Jan 2024 09:30:00 GMT

すべてのHTTP timestampヘッダーは、RFC 2822フォーマットのサブセット、具体的にはRFC 7231の「推奨」フォーマット：Day, DD Mon YYYY HH:MM:SS GMTを使用します。タイムゾーンは常にGMT（この目的ではUTCと機能的に同等）でなければなりません。

各ヘッダーの動作：

Date — サーバーがレスポンスを生成した時刻。ほとんどのWebサーバーが自動的に設定します。キャッシュがレスポンスの経過時間を計算するために使用します。

Last-Modified — リソースが最後に変更された時刻。条件付きリクエストを可能にします：クライアントがこの値とともにIf-Modified-Sinceを送信し、何も変更がなければサーバーは304 Not Modifiedを返して帯域幅を節約します。

# クライアントリクエスト
GET /api/data HTTP/1.1
If-Modified-Since: Sun, 14 Jan 2024 20:00:00 GMT

# サーバーレスポンス（変更なし）
HTTP/1.1 304 Not Modified

Expires — レスポンスが古くなる時刻。この時刻以降、キャッシュは再検証が必要です。絶対的な日付の代わりに秒数で指定するCache-Control: max-ageにほぼ取って代わられています。

Cache-Control — フォーマット済み日付ではなく、相対的な秒数を使用：

Cache-Control: max-age=3600    # 1時間有効
Cache-Control: s-maxage=86400  # CDNは1日間キャッシュ可能

よくある落とし穴：

未来の日付のLast-Modified値を送信すると、キャッシュの動作が未定義になります。過去の日付のExpiresを送信すると、キャッシュにレスポンスがすでに古いことを伝えます（キャッシュの無効化のために意図的に使用されることがあります）。ExpiresとCache-Control: max-ageの両方が存在する場合、max-ageが優先されます。

ETag vs. Last-Modified： 1秒に複数回変更されるリソースの場合、Last-Modifiedは変更を検出する精度が不足しています。代わりにETag（ハッシュまたはバージョン識別子）を使用してください。多くのシステムは最大限の互換性のために両方を使用しています。