If-Modified-Since Inspect

キャッシュ関連ヘッダーを横断して判定します。入力はサーバーへ送信しません。再検証やCDN差分の一次切り分けに使えます。

状態

ブラウザ内で処理します。入力はサーバーへ送信しません。まずはここで一次切り分けしてください。

使い方

If-Modified-Since か Request Headers を貼り付けて「解析」。日時を読みやすく表示します。

注意（このツール）

  • If-Modified-Since: のヘッダー行でも解析できます（複数行の貼り付けもOK）。

このページについて

何をするツール？

If-Modified-Since を分解し、日時をUTC/ローカルで見やすく表示します。

304 Not Modified の挙動やキャッシュ検証の切り分けに向きます。

基本（If-Modified-Since の役割）

  • If-Modified-Since は「この日時以降に更新があれば取得」の条件です。
  • 一致すれば 304、更新があれば 200 が返るのが一般的です。
  • 対になるのは Last-Modified です。

入力の例

  • If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT
  • Request Headers をまるごと貼り付け

よくある落とし穴

  • Last-Modified が無く、If-Modified-Since が効かない
  • サーバー時刻のズレで 304 にならない
  • ETag と併用時に挙動が揺れる（優先順位に注意）

切り分け手順（おすすめ）

  • Last-Modified Inspect で値を確認
  • このツールで If-Modified-Since を解析
  • ETag Inspect で ETag との併用有無を確認
  • Last-Modified Inspect
  • ETag Inspect
  • Response Headers Parser

推奨（実務）

  • Last-Modified と必ずセットで運用
  • Cache-Control: no-cache と合わせて再検証を促す
  • API/HTML は validators を必ず付与

このツールでできること

  • If-Modified-Since の日時を整理
  • 304 挙動の確認ポイントの提示

注意（運用）

  • キャッシュ挙動はブラウザ/CDN/プロキシの層で変わるため、同一点観測で比較してください。
  • ヘッダー診断だけでは不十分な場合があります。アプリ側の更新戦略とキー設計も確認してください。

参照仕様

  • RFC 9110（HTTP Semantics）
  • MDN: If-Modified-Since

FAQ

If-Modified-Since と If-None-Match の違いは？

If-None-Match は ETag による厳密な検証、If-Modified-Since は日時ベースの検証です。

参考リンク

  1. RFC 9110
  2. MDN: If-Modified-Since

site_map ルールに基づいて、次に確認すべきページを表示しています。

  1. 304が返らない時の診断手順 — ETag / Last-Modified と If-* の往復を確認して 304 不発を切り分ける
  2. If-None-Match Inspect — If-None-Match を解析して再検証条件を確認
  3. Age Inspect — Age を解析して共有キャッシュ滞在時間を把握
  4. If-Unmodified-Since Inspect — If-Unmodified-Since を解析して更新競合条件を確認
  5. Expires Inspect — Expires / Date を解析して期限挙動を確認
  6. Cache Validator Overview — ETag/Last-Modified 系バリデータの関係を整理
  7. ETag Inspect — ETag と If-None-Match の整合を解析
  8. ETag Builder — 用途に応じたETag値を生成

キャッシュ検証

ETag/Last-Modified と If-* をつないで再検証フローを判断