HTTP ツール
HTTP のステータスとリダイレクトの意味、Cache-Control ディレクティブ、ヘッダーや URL、User-Agent、OGP がおかしいときにどのツールで何をどう確かめるかまで、実務のデバッグ手順を前提にまとめた HTTP のリファレンスです。
9 ツール
HTTP のやり取りを4層に分けて見る
HTTP のデバッグは、URL(何を要求したか)・リクエストヘッダー(何者だと申告し何を受け取るか)・ステータス行(判定)・レスポンスヘッダー(キャッシュ・セキュリティ・Content-Type を決める契約)を分けて見ることから始まります。ボディが壊れる時点で、理由はヘッダーが語っています。
ブラウザに見える内容も origin の生の出力ではありません。間には CDN、プロキシ、HTTP/2 や /3(フィールド名は小文字化)、Service Worker、キャッシュが挟まり、200 OK (from disk cache) はレスポンスではなくその記憶です。User-Agent も偽装できる自己申告で、確実なのは origin が返すステータスとヘッダーだけです。
ステータスクラスの早見表
| クラス | 意味 | クライアントの動作 | ヒューリスティックキャッシュ可 |
|---|---|---|---|
1xx | 中間応答(100・101・103) | 待ち続ける | 不可 |
2xx | 成功 | ボディを使う(204 は本文なし) | 200・203・204・206 |
3xx | リダイレクト / 再検証 | Location を辿る。304 はキャッシュを再利用 | 300・301・308 |
4xx | 要求の内容が誤り | 直して送り直す。盲目的に再試行しない | 404・405・410・414 |
5xx | 正しい要求にサーバーが失敗 | バックオフし Retry-After に従う | 501 のみ |
右端は、Cache-Control も Expires も無いレスポンスをキャッシュが独自判断で再利用してよいコードです(RFC 9110 §15.1)。404 や 410 も含まれるため、削除したページに no-store を付けないと「消したはずのページが消えない」ことが起こります。5xx で該当するのは 501 だけです。扱いを誤りやすいのは 429 と 304 で、前者には Retry-After を必ず付け、後者は成功なのでエラー扱いするとキャッシュが効いている事実が障害に見えます。
リダイレクトの選択表
| コード | 恒久性 | メソッドとボディ | 用途 |
|---|---|---|---|
301 | 恒久 | 保持されない(GET 化されうる) | URL 改名・ホスト統合 |
302 | 一時 | 保持されない | 旧来の既定。POST には使わない |
303 | 一時 | 保持されない(GET 化) | POST 後に結果ページへ |
307 | 一時 | 保持される | エンドポイントの一時移動 |
308 | 恒久 | 保持される | POST エンドポイントの恒久移動 |
301 はブラウザに強くキャッシュされ、消すまで残ることもあるため取り消しが高くつきます。必ずステージングで確認してください。
Cache-Control の読み方
| ディレクティブ | 制御対象 | 補足 |
|---|---|---|
max-age=N | 全キャッシュの鮮度(秒) | 0 は毎回再検証 |
s-maxage=N | 共有キャッシュの鮮度のみ | CDN で max-age を上書き |
no-cache | 保存は可、再利用前に再検証 | no-store と別物 |
no-store | 保存そのものを禁止 | 認証後の HTML |
private | 共有キャッシュに保存させない | 個人向け |
immutable | 鮮度内は再検証しない | ハッシュ付き静的資産 |
Vary も同じで、Accept-Language などで内容が変わるのに宣言しなければ共有キャッシュが別バリアントを配ります。
どのツールで何を確かめるか
origin 自身の応答を見たいときは HTTPヘッダーチェッカー。api.sitekits.dev から実行するので拡張機能やキャッシュが経路に入らず、最終ステータス・最終 URL・リダイレクト回数・全ヘッダーが分かります(ヘッダーのみ取得、localhost は対象外)。
送る側を試すなら REST APIテスター。ブラウザから対象へ直接送るので対象の CORS がそのまま効き、OPTIONS でプリフライトも見られます。トークンは JWTデコーダー で exp とクレームを確認(デコードは検証ではありません)。
壊れている単位が1リクエストではなくページ全体なら、DevTools の Network から HAR を書き出して HARビューアー へ。エントリがメソッド・ステータス・種別・サイズ・時間の表になり 4xx/5xx が色付きで浮くので、遅いのか落ちているのかを一画面で絞り込めます(読み方は HAR ガイド)。
疑いが URL 自体に向いたときは URLパーサー が先です。WHATWG パーサーでスキームからフラグメントまで分解し、クエリはパーセントデコード済みの表になるため、OAuth のコールバックや署名付き URL で「どのパラメータが落ちたか」がその場で分かります。値が %2520 のように壊れていれば二重エンコードなので、URLエンコード で1段ずつ戻します。
ステータスもボディも正常なのに挙動が合わないなら、疑うのは申告値か型定義です。ログの振り分けや bot 判定がずれているときは UserAgentパーサー がブラウザ・OS・デバイス種別と bot ヒューリスティックまで分解します(自己申告値なので手掛かり止まりです)。コードの意味を引くだけなら HTTPステータスコード を番号か語句で絞り込むのが速く、表示されるはずのファイルがダウンロードされる症状は MIMEチェッカー で拡張子に対応する Content-Type を確かめます。レスポンス自体は正常なのに共有カードだけ崩れるときは、ページの HTML を OGプレビュー に貼ります。取得ではなく貼り付け解析なので、ステージングビルドやログインの内側でも使えます。
つまずきやすい点
平文 HTTP に載せた HSTS は無効
HTTP 経由の Strict-Transport-Security は無視され、Secure Cookie も破棄されます。80番はリダイレクトのみ、ヘッダーは HTTPS 側に付けます。
セキュリティヘッダーはレスポンス単位
HTML の Content-Security-Policy は API の JSON や CDN のエラーページに効きません。CSPジェネレーター で組んでも、載るかはデプロイ設定次第。
リダイレクトの連鎖は往復回数を増やす
http://example.com → https://example.com → https://www.example.com/ → /home/ は、HTML が1バイトも届く前に3往復を余分に消費し、しかも各ホップでメソッド・Cookie・クエリ文字列が落ちる余地があります。エッジで1ホップに畳んでください。
ボディにエラーを入れた 200 は監視をすり抜ける
{"error": ...} を 200 で返すとステータス基準のアラートから障害が消え、可用性が過大に見えます。SLO を持つなら本文も検査を(SRE の道具)。
+ と %20 は入れ替えられない
application/x-www-form-urlencoded として解釈されるクエリ文字列では + は空白にデコードされますが、パスセグメントでは文字どおりのプラス記号です。兄弟のような不具合が二重エンコードで、%20 が %2520 になると、エスケープではなくルーティングの問題に見えます。