Content-Encoding Inspect

HTTPヘッダー/経路情報をブラウザ内で整理・診断します。入力はサーバーへ送信しません。観測差分の一次切り分けに使えます。

状態

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

使い方

Content-Encoding か Response Headers を貼り付けて「解析」。適用された圧縮方式と注意点を整理します。

注意（このツール）

  • Content-Encoding: のヘッダー行でも解析できます（複数行の貼り付けもOK）。
  • 複数のエンコーディングが列挙される場合、適用順（スタック）として扱います。

このページについて

何をするツール？

Content-Encoding を分解して、実際に適用された圧縮方式（br/gzip/deflate/zstd など）を一覧表示します。

圧縮が効かない、解凍に失敗する、CDNで混在するなどの切り分けに向きます。

基本（Content-Encoding と Accept-Encoding）

  • Content-Encoding は「実際に使った圧縮方式」です。
  • Accept-Encoding は「クライアントが受け付ける方式」です。
  • 圧縮を使う場合は Vary: Accept-Encoding が基本です。

複数エンコーディング（スタック）

Content-Encoding は複数列挙されることがあります。基本的に「右から順に適用」されたと考えて読みます。

  • 例: Content-Encoding: br, gzip は「gzipで圧縮してからbrを適用」。
  • スタックが深いと互換性や復号の失敗原因になります。

代表的な圧縮方式

  • br: Brotli（HTTPS/静的アセットでよく使われる）
  • gzip: 互換性が高い定番
  • zstd: 高速・高圧縮だが対応状況は環境差あり
  • deflate: レガシーな実装差があるため注意
  • identity: 無圧縮（通常は Content-Encoding に出ません）

キャッシュと Vary: Accept-Encoding

同じURLでも Content-Encoding が変わる場合、キャッシュ混在を避けるために Vary: Accept-Encoding が重要です。

  • Vary が無いと、圧縮方式が違うレスポンスが混在しやすい
  • CDNは Accept-Encoding でキャッシュ分岐するのが基本

よくある落とし穴

  • Content-Encoding があるのに Accept-Encoding に含まれていない方式を返している
  • Content-Encoding と Content-Length が矛盾している（圧縮前/後の混在）
  • 既に圧縮済みのファイルを再圧縮してサイズが増える
  • スタックの順序誤りでクライアントが解凍できない

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

  • Response Headers Parser で Content-Encoding を抽出
  • Accept-Encoding Inspect でクライアントの許可方式を確認
  • Vary Inspect で Vary: Accept-Encoding の有無を確認
  • Accept-Encoding Inspect
  • Vary Inspect
  • Response Headers Parser
  • Request Headers Parser
  • Cache-Control Inspect
  • Age Inspect
  • Via Inspect

このツールでできること

  • Content-Encoding の分解と適用順の整理
  • 代表的な注意点の提示
  • 関連ヘッダー確認ポイントの提示

注意（運用）

  • 中継機器でヘッダーが書き換わることがあります。取得地点を揃えて比較してください。
  • 最終判断はサーバーログと設定（信頼プロキシ、ルーティング）で確認してください。

参照仕様

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

FAQ

Content-Encoding が無いのは問題？

圧縮していない場合は通常付きません。静的アセットなどで圧縮を期待しているなら設定を確認してください。

br と gzip は併用できる？

Content-Encoding に複数並ぶ場合はスタックされますが、互換性の観点から単一が一般的です。

Content-Length は圧縮前/後どちら？

Content-Encoding がある場合、一般に「圧縮後」のサイズです。

参考リンク

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

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

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

圧縮/転送

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