HTTP レスポンスヘッダー解析

開発ツール

読み込み中

ツールを読み込んでいます

ツールのコードは開いたときにのみ読み込まれます。

このツールの処理はすべてブラウザー内で行われ、入力内容はサーバーへ送信されません。

このツールについて

開発者ツールやコマンドラインの記録からレスポンスヘッダーを貼り付け、ブラウザー内で確認できます。ステータス行は任意で、重複ヘッダーは個別に保持します。Set-Cookie の日付に含まれるカンマも分割しません。レスポンスのブロックを選び、キャッシュ、コンテンツタイプ、Location、CORS、状況に応じた安全性の確認点を調べます。解析機能はリクエストの送信、入力履歴の保存、ヘッダー情報のテレメトリー送信を行いません。値はプレーンテキストとして表示し、HTML を実行しません。コピーや出力には秘密情報が残り得ます。このツールはマスキングを行いません。

主な用途

記録した API や静的ファイルのレスポンスでキャッシュ指示を比較し、ブラウザーや CDN の設定を確認する。
重複ヘッダーを調べ、貼り付けたリダイレクトや暫定レスポンスの列から個別のレスポンスを選ぶ。
宣言された MIME タイプ、文字コード、リダイレクト先、CORS ヘッダーを確認し、不明なリクエスト条件を区別する。

使い方

1.レスポンスヘッダーだけを貼り付けます。先頭には HTTP/1.1 200 OK などのステータス行を付けられます。複数のレスポンスは空行で区切り、2 つ目以降は必ずステータス行で始めてください。上限は UTF-8 で 256 KiB、4,000 行、32 ブロックです。
2.解析し、行番号と列番号が示されたエラーを修正してから、確認するレスポンスを選びます。元の通信方式が分かる場合だけ HTTPS または HTTP を指定し、それ以外は「不明」のままにします。
3.保持されたフィールドと分類別の確認点を、元のリクエストと合わせて読みます。Cookie、トークン、個人を識別できる URL などを確認してから、選択したブロックの JSON レポートをコピーまたはダウンロードしてください。

架空のレスポンスヘッダーによる例

有効期限の日付にカンマがある 2 つの Cookie

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
X-Content-Type-Options: nosniff
Set-Cookie: session=demo-session; Expires=Wed, 21 Oct 2026 07:28:00 GMT; Secure; HttpOnly
Set-Cookie: theme=dark; Path=/; SameSite=Lax

1 レスポンスブロック · 独立した Set-Cookie フィールドが 2 個
宣言された MIME タイプ：text/html · 文字コード：utf-8
X-Content-Type-Options：nosniff

日付のカンマは最初の Cookie 値の中に保持します。nosniff は宣言された MIME タイプに従うようブラウザーに指示しますが、解析機能は本文を読み込まず、HTML であるかも検証しません。架空の Cookie 値は両方とも表示され、出力時にもマスクされません。

リダイレクトと後続レスポンスを個別に選ぶ

HTTP/1.1 301 Moved Permanently
Location: /docs
Cache-Control: max-age=300

HTTP/2 200
Content-Type: application/json
Cache-Control: no-cache
ETag: "demo-v2"

2 レスポンスブロック：301、続いて 200
最初のブロック：Location /docs · max-age=300
次のブロック：application/json · no-cache · ETag "demo-v2"

各ブロックを個別に選択します。相対 Location の解決には元のリクエスト URL が必要で、このツールからアクセスすることはありません。後続レスポンスはキャッシュ再利用前に検証が必要ですが、no-cache 自体は保存を禁止しません。2 つが実際に同じリダイレクト列に属するかは推定しません。

矛盾する保存指示を確認する

HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Cache-Control: public, private, max-age=600, no-store

public と private の併記は要確認
max-age=600 があっても no-store は保存を禁止

設定の確認例として、意図的に矛盾した指示を並べています。鮮度寿命は no-store に優先しません。10 分間保存されると思い込まず、このレスポンスを作ったサーバーと中間層の設定を調べてください。

ステータス行を省いた CORS ヘッダー

Content-Type: application/json
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

1 レスポンスブロック · ステータス不明
ワイルドカードのオリジンと認証情報の許可は要確認
実際の CORS の成否：不明

最初のブロックはステータス行を省略できます。この組み合わせでは認証情報付き CORS レスポンスを許可できませんが、貼り付けた情報からは認証情報の使用やクロスオリジンアクセスの必要性までは分かりません。

ヘッダー解析でよくある間違い

本文全体、curl コマンド、リクエスト行を貼り付ける：レスポンスヘッダーだけをコピーしてください。対応する表記のステータス行は付けられます。
コロンを忘れる、フィールド名に空白を入れる：Name: value 形式にし、表示された行番号と列番号を修正してください。旧式の複数行ヘッダーは拒否されます。
ステータス行のないヘッダー群を空行で区切る：省略できるのは最初だけで、2 つ目以降のブロックは新しいステータス行で始める必要があります。
HTTP/2 を HTTPS の証明、セキュリティヘッダーの欠落を脆弱性の証明、CORS の注意を通信失敗の確定とみなす：不足している条件を確認してください。
no-cache と no-store を混同する、max-age をブラウザーや CDN での保存期間の保証とみなす：適用される全指示とリクエストを確認してください。
出力がマスキング済みだと思って共有する：元の Cookie、トークン、Location のクエリ文字列、独自ヘッダーの値を自分で確認してください。

制限と注意事項

入力上限は 256 KiB（262,144 UTF-8 バイト）、4,000 行、32 レスポンスブロックです。入力が拒否された場合、途中までの解析結果は出しません。小さくても完全なヘッダー部分を使うと確認しやすくなります。
テキスト用のパーサーであり、ネットワーククライアントや通信プロトコル全体の検証器ではありません。テキスト記録の HTTP/1.0、HTTP/1.1、HTTP/2、HTTP/3 ステータス行表記に対応します。リクエスト行、レスポンス本文、HTTP/2 の疑似ヘッダー、旧式の折り返し継続行には対応しません。
レスポンスヘッダーだけでは、実際のキャッシュ再利用、CORS の成否、元のリクエスト URL が不明な相対 Location の行き先、宣言された MIME タイプや文字コードと本文の一致は確定できません。Location へのアクセスやエンドポイントのテストは行いません。
安全性の表示は条件付きの確認点であり、評価点や脆弱性の証明ではありません。HSTS の説明は元の通信方式に依存し、HTTP/2 や HTTP/3 の表記だけから HTTPS とは判断できません。ヘッダーの存在だけでは、ポリシー、TLS 設定、アプリケーションの正しさは確認できません。
コピーとダウンロードの対象は、選択したレスポンスブロックとその解析結果だけです。ほかのブロックは含みません。元の値は残り、認証情報、Set-Cookie の値、内部ホスト名、識別子を削除しません。ローカル処理やプレーンテキスト表示は、安全に共有できる保証にはなりません。ダウンロードしたファイルは端末に保存されます。

よくある質問

no-cache はレスポンスの保存を禁止しますか？

いいえ。引数のない no-cache は保存済みレスポンスを再利用する前の検証成功を要求し、no-store は通常保存を禁止します。ただし、must-understand を理解して実装するキャッシュには仕様上の例外があります。max-age は秒単位の鮮度寿命を指定し、共有キャッシュでは s-maxage が優先します。引数のない private は共有キャッシュへの保存を禁止し、public は適用ルールの下で共有キャッシュを許可します。ほかの指示やリクエスト条件も重要で、矛盾する値は確認が必要です。

このヘッダーだけでクロスオリジンの通信が成功すると分かりますか？

分かりません。リクエストの Origin、認証情報の送信モード、メソッド、ヘッダー、必要ならプリフライトの内容も関係します。Access-Control-Allow-Credentials: true があっても、Access-Control-Allow-Origin: * は認証情報付き CORS レスポンスを許可できません。クロスオリジンのスクリプトアクセスを想定しないリソースでは、CORS ヘッダーの欠落が問題とは限りません。

なぜ HTTP か HTTPS かを自分で選ぶのですか？

貼り付けたステータス行には、元の URL スキームが含まれないためです。ブラウザーは HTTP で受け取った Strict-Transport-Security を無視し、HSTS は HTTPS 経由で設定されます。1 回の記録にヘッダーがなくても、以前保存された HSTS ポリシーの有無は分かりません。確認できる通信方式だけを選び、結果は追加調査の手がかりにしてください。

重複ヘッダーをまとめずに残すのはなぜですか？

フィールドごとに結合のルールが異なるためです。Set-Cookie は個別に扱い、Expires の日付内のカンマで Cookie を分割してはいけません。このツールは元のフィールド順序と値を保持するため、秘密情報も残ります。コピーや出力で自動的にマスキングされることはありません。