Response Headers系ツールの使い分け

レスポンスヘッダー系は「全体把握 → 個別ヘッダー深掘り」の順で見ると、原因特定が速くなります。

最初に選ぶ1本（症状ベース）

まず全体を分解したい → Response Headers Parser
429/503で待機時間を読みたい → Retry-After Inspect
遅延要因を見たい → Server-Timing Inspect
preload/canonical/next/prev を確認したい → Link Header Inspect
MIME宣言と nosniff を確認したい → Content-Type Inspect + X-Content-Type-Options Inspect

ツール役割マップ

HTTP Header Parser: 生ヘッダー貼り付け時の入口
Response Headers Parser: レスポンス全体を構造化
Retry-After Inspect: 再試行タイミング（秒/日時）の解釈
Server-Timing Inspect: 指標分解で遅延要因候補を抽出
Link Header Inspect: rel/as/type/crossorigin の整合確認
Content-Type Inspect + X-Content-Type-Options Inspect: MIME宣言と nosniff の整合確認

実務フロー（推奨）

1) Response Headers Parser で全体を取り込み、対象ヘッダーを特定する
2) 症状に対応する専用ツール（Retry-After / Server-Timing / Link / Content-Type）へ分岐する
3) 必要に応じて HTTP Status Inspect と組み合わせ、ステータス文脈で解釈する
4) 変更後に同一URLで再取得し、差分が期待通りか確認する

調査時の採取セット

同一URLの response headers（問題発生時刻）
HTTPステータス、Date、Retry-After（該当時）
Server-Timing の raw 値（改行なしで控える）
Content-Type / X-Content-Type-Options / Link の実値

比較対象ツール

よくあるケース

429でクライアントが即再試行してしまう（Retry-After未解釈）
Server-Timing があるのに遅延要因が分からない（name/dur設計不足）
preload 設定したのに効かない（Link の as/crossorigin 不整合）
nosniff は付けたが Content-Type 誤配信で表示不具合

よくある誤り

1つのヘッダーだけ見て全体文脈（ステータス・他ヘッダー）を無視する
Retry-After 秒指定をミリ秒として扱う
Server-Timing の desc に内部情報を出しすぎる
nosniff だけで安全と判断し、Content-Type 側を放置する

FAQ

Response Headers Parser と HTTP Header Parser はどう違いますか？: HTTP Header Parser は生ヘッダーの入口、Response Headers Parser はレスポンス観点の構造化と次アクション選定に向いています。
どのタイミングで専用ツールに分岐すべきですか？: Retry-After、Server-Timing、Link、Content-Type など対象ヘッダーが特定できた時点で専用ツールに進むのが効率的です。

参照仕様

次に見る（診断順）

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

HTTP Header Parser — 生ヘッダーを構造化して一覧化
Response Headers Parser — レスポンスヘッダーを構造化解析
Retry-After Inspect — Retry-After を解析して再試行待機を確認
Server-Timing Inspect — Server-Timing を分解して遅延指標を確認
Link Header Inspect — Link ヘッダーを解析して rel/as/type を確認
Content-Type Inspect — Content-Type を解析してMIME/charsetを確認
X-Content-Type-Options Inspect — X-Content-Type-Options を解析して nosniff を確認
HTTP Status Inspect — HTTPステータスコードを解析して対処方針を確認