Accept-Encoding Inspect

入力値の整形・変換・判定をブラウザ内で実行します。入力はサーバーへ送信しません。形式差分の一次切り分けに使えます。

状態

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

使い方

Accept-Encoding か Response Headers を貼り付けて「解析」。圧縮方式と優先度（q）を整理します。

注意（このツール）

  • Accept-Encoding: のヘッダー行でも解析できます（複数行の貼り付けもOK）。
  • q は 0.0〜1.0 の優先度です。q=0 は「受け付けない」の意味です。

このページについて

何をするツール？

Accept-Encoding を分解して、受け付け可能な圧縮方式（br/gzip/deflate/zstd など）と優先度（q）を一覧化します。

圧縮が効かない、CDNで表示が混ざる、同じURLで内容が変わるといったトラブルの切り分けに向きます。

基本（Accept-Encoding と Content-Encoding）

  • Accept-Encoding は「クライアントが受け付けられる圧縮方式」です。
  • Content-Encoding は「実際にサーバーが使った圧縮方式」です。
  • 圧縮を配信するなら Vary: Accept-Encoding が基本です。

q 値（優先度）の読み方

  • q=1.0 が最優先、q が小さいほど優先度が低い。
  • q=0 は「受け付けない」を意味します。
  • 明示されない場合は q=1.0 とみなされることが多い。

入力の例

  • Accept-Encoding: br, gzip, deflate
  • Accept-Encoding: gzip;q=1.0, br;q=0.8, *;q=0
  • Response Headers をまるごと貼り付け

代表的な圧縮方式

  • br: Brotli（HTTPS/静的アセットでよく使われる）
  • gzip: 互換性が高い定番
  • zstd: 高速・高圧縮だが対応状況は環境差あり
  • deflate: レガシーな実装差があるため注意
  • identity: 無圧縮（明示されない場合もあります）
  • *: 上記以外の方式

キャッシュと Vary: Accept-Encoding

同じURLでも圧縮方式によってバイト列が変わるため、キャッシュは Accept-Encoding を分岐に含める必要があります。

  • Vary が無いと、gzipを期待しているのに br が返るなどの混在が起きます。
  • Vary を増やしすぎるとキャッシュが割れるため、必要最小限にします。

よくある落とし穴

  • Accept-Encoding はあるのに Content-Encoding が付かず、圧縮されていない
  • Vary: Accept-Encoding が無く、CDNで表示が混ざる
  • すでに圧縮済みのファイルを再圧縮し、サイズやCPUが悪化
  • deflate の互換性差でクライアント側が解凍失敗

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

  • Request Headers Parser で Accept-Encoding を確認
  • Response Headers Parser で Content-Encoding と Vary を確認
  • このツールで q 値と許可範囲を整理
  • Vary Inspect
  • Response Headers Parser
  • Request Headers Parser
  • Content-Type Inspect
  • Cache-Control Inspect
  • Age Inspect
  • Via Inspect

このツールでできること

  • Accept-Encoding の分解と優先度（q）の整理
  • 許可される圧縮方式の整理（identity/* 含む）
  • 関連ヘッダー確認ポイントの提示

注意（運用）

  • 同じ文字列でも文脈により解釈規則が異なります。利用先仕様を優先してください。
  • 入力元での自動変換（空白、改行、URLデコード）に注意してください。

参照仕様

  • RFC 9110（HTTP Semantics）
  • RFC 9111（HTTP Caching）
  • MDN: Accept-Encoding

FAQ

Accept-Encoding が空でも動く？

多くのクライアントは Accept-Encoding を送りますが、送られない場合はサーバーが圧縮しない（identity）ことが一般的です。

Vary: Accept-Encoding は必須？

同じURLで圧縮方式が変わるなら、キャッシュ混在を防ぐために付けるのが基本です。

br が無いのに br で返ることはある？

原則はクライアントの許可に従います。クライアントが未対応の圧縮を受け取ると壊れて見えることがあります。

参考リンク

  1. RFC 9110
  2. RFC 9111
  3. MDN: Accept-Encoding
  4. MDN: Content-Encoding
  5. MDN: Vary

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

  1. Content-Encoding Inspect — Content-Encoding を解析して実際の圧縮方式を確認
  2. Transfer-Encoding Inspect — Transfer-Encoding を解析して転送方式を確認
  3. Content-Length Inspect — Content-Length を解析してサイズ整合を確認
  4. Vary Inspect — Vary を解析してキャッシュ分岐条件を可視化

圧縮/転送

Accept/Content/Transfer-Encoding と Vary から圧縮不整合を切り分け