HTTP 304 Not Modified：意味と概要

このエラーの意味と見分け方

• ブラウザの開発者ツール、API クライアント、監視ツール、チェッカーがステータス 304 Not Modified を報告する。
• レスポンスにキャッシュ関連またはバリデータのヘッダーは含まれるが、リソース本文がない。
• ブラウザはキャッシュ済みの表現を再利用するため、ページを正常に表示することがある。
• API クライアントやチェッカーが条件付きキャッシュを正しく実装していない場合、空のレスポンスを受け取ったように見えることがある。
• 影響があるのは Web サイト全体ではなく、1 つの URL やリソースだけの場合がある。
• クライアントは HTTP エンドポイントに到達して HTTP レスポンスを受け取っているため、DNS と TLS は引き続き正常に動作している可能性がある。

可能性の高い順の主な原因

1. クライアントが条件付きリクエストを送信した。 If-None-Match や If-Modified-Since などのリクエストヘッダーによって、キャッシュ済みの表現が現在も有効かどうかを確認した。
2. リソースが変更されていない。 サーバーまたは中間レイヤーが、ETag や Last-Modified など、提示されたバリデータと一致することを確認し、正しく 304 を返した。
3. ブラウザ、プロキシ、CDN が通常のキャッシュ検証を実行した。 レスポンスはオリジンアプリケーションではなく、中間レイヤーが生成した可能性がある。
4. クライアントまたは監視ツールが、通常のキャッシュレスポンスをエラーとして表示した。 完全なレスポンス本文を想定する設定になっており、保存済みのコピーを再利用しないツールもある。
5. バリデータまたはキャッシュ設定に一貫性がない。 アプリケーションのデプロイ、プロキシルール、オリジンのヘッダーによって、古い、競合する、または対象範囲が広すぎるキャッシュバリデータが生成されると、予期しない結果が発生することがある。

HTTP 304 自体は、リダイレクト、認証失敗、レート制限のレスポンス、サーバー停止を意味しません。これらの状態は、304 から推測するのではなく、実際のステータス、ヘッダー、ログで確認してください。

修正方法

訪問者向け

1. まずブラウザにレスポンスを処理させます。 通常のブラウザは 304 を受け取ると、キャッシュ済みのコピーを使用します。ページが正しく表示される場合、通常は対応不要です。
2. 正確な URL を確認します。 ホスト名、パス、クエリ文字列、プロトコルを確認してください。URL が異なれば、キャッシュ済みの表現も別になることがあります。
3. 表示内容が古い、または不完全な場合は、1 回だけ再試行します。 繰り返し更新するのではなく、ブラウザの通常の再読み込み操作を使用してください。
4. 必要な場合にのみ、別のクライアントと比較します。 あるブラウザでは古い内容が表示され、別のブラウザでは表示されない場合は、対象 URL、おおよその時刻、クライアントの挙動を記録してサイト所有者に伝えます。
5. リソースを読み込めない場合は、サイト所有者に連絡します。 URL とタイムスタンプを報告しますが、パスワード、Cookie、認証ヘッダーなどの非公開データは共有しないでください。

開発者・サイト所有者向け

1. リクエストとレスポンスの完全なコンテキストを取得します。 HTTP メソッド、関連するクエリパラメーターを含む完全な URL、ステータス、リクエストのバリデータ、レスポンスのバリデータ、Cache-Control、Vary、プロキシまたは CDN のヘッダーを記録します。共有する前に認証情報と個人データを削除してください。
2. リクエストが条件付きであることを確認します。 If-None-Match または If-Modified-Since を確認してください。304 は通常、クライアントが検証可能なキャッシュ済みの表現を持っている場合に意味を持ちます。
3. レスポンスを生成したレイヤーを確認します。 304 がブラウザ、ローカルまたは共有プロキシ、CDN、リバースプロキシ、Web サーバー、アプリケーションのどこから返されたかを特定します。利用可能であれば、そのコンポーネントのリクエスト ID とタイムスタンプを使用します。
4. バリデータとリソースを比較します。 ETag または Last-Modified が要求された表現を正確に表していることを確認します。また、関連する場合は、コンテンツネゴシエーションが適切な Vary ポリシーで処理されていることを確認します。
5. 現在の本文が必要な場合は、条件なしのリクエストをテストします。 許可された診断クライアントを使用するか、管理されたテスト環境で条件付きリクエストヘッダーを一時的に省略します。これは読み取り専用の比較ですが、サービスの通常のアクセス制御に従い、信頼できないツールに機密ヘッダーを送信しないでください。
6. 最近のキャッシュやデプロイの変更を確認します。 アプリケーションのリリース、アセット生成、プロキシまたは CDN ルール、圧縮とコンテンツネゴシエーション、ルーティング、キャッシュ無効化の動作を確認します。すぐにグローバル設定を変更するのではなく、対象のルートに影響する変更に注目します。
7. 安全性を確認したうえで、最も範囲の狭い修正を適用します。 不一致を特定してから、バリデータ、キャッシュポリシー、中間レイヤーのルールを修正します。1 つのルートまたは表現だけに影響している場合、キャッシュをグローバルに無効化することは避けてください。
8. 同じリクエスト経路を再テストします。 条件付きリクエストと新規リクエストの両方をテストし、関連するルートとリクエストメソッドが意図したステータスと表現を引き続き返すことを確認します。

予防と修正確認

• クライアントがキャッシュ済みの表現を利用できない場合を除き、監視では 304 を想定されるキャッシュ検証の結果として扱います。
• デプロイ後は、重要なルートを通常のリクエストと条件付きリクエストの両方でテストします。
• ETag、Last-Modified、Cache-Control、Vary の動作を意図的に設計し、文書化します。
• 配信される表現が変更されたとき、関連するコンテンツネゴシエーションのバリエーションも含めて、キャッシュバリデータが変更されるようにします。
• ルート別、キャッシュレイヤー別にステータスの割合を監視し、予期しない 304 のパターンを通常のブラウザトラフィックと区別できるようにします。
• 可能な範囲で、プロキシ、CDN、Web サーバー、アプリケーションの設定をバージョン管理します。
• サニタイズ済みのリクエスト ID とタイムスタンプを、報告をレスポンス生成レイヤーと照合できる期間だけ保持します。

よくある質問