ETag Builder

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

 

状態

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

使い方

ETag値を入力して「生成」。ETag ヘッダー文字列をコピーできます。

注意（このツール）

  • 値は自動でダブルクォートで包みます。

このページについて

何をするツール？

ETag の文字列を生成し、W/（weak）指定を切り替えます。

キャッシュ検証（If-None-Match / If-Match）のテスト用に便利です。

基本（ETag の役割）

  • ETag はリソースのバージョン識別子です。
  • If-None-Match / If-Match で条件付きリクエストに使います。
  • W/ は弱い比較（意味的な同一）を表します。

入力の例

  • ETag 値: abc123 → ETag: "abc123"
  • Weak: ON → ETag: W/"abc123"

よくある落とし穴

  • ETag が毎回変わり 304 が効かない
  • weak/strong の使い分けを誤る

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

  • ETag Builder で ETag を生成
  • If-None-Match Inspect / If-Match Inspect で条件を確認
  • HTTP Status Inspect で 304/412 を確認
  • ETag Inspect
  • If-None-Match Inspect
  • If-Match Inspect

このツールでできること

  • ETag 文字列の生成
  • weak/strong の切り替え

注意（運用）

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

参照仕様

  • RFC 9110（HTTP Semantics）
  • MDN: ETag

FAQ

Weak ETag と Strong ETag はどう使い分けますか？

バイト単位一致が必要なら strong、意味的同一で十分なら weak を使います。

ETag が毎回変わると何が問題ですか？

304 再検証が成立しにくくなり、帯域と応答時間に悪影響が出ます。

参考リンク

  1. RFC 9110
  2. MDN: ETag

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

  1. ETag Policy Checker — ETag運用ポリシーの妥当性を点検
  2. If-Match Inspect — If-Match を解析して更新前提条件を確認
  3. Pragma Cache Inspect — Pragma を解析して旧キャッシュ制御を確認
  4. Cache Validator Overview — ETag/Last-Modified 系バリデータの関係を整理
  5. ETag Inspect — ETag と If-None-Match の整合を解析
  6. If-None-Match Inspect — If-None-Match を解析して再検証条件を確認
  7. If-Modified-Since Inspect — If-Modified-Since を解析して条件付き取得を確認
  8. If-Unmodified-Since Inspect — If-Unmodified-Since を解析して更新競合条件を確認

キャッシュ検証

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