今回やること
この記事では、HTTPレスポンスを読みます。
レスポンスは「処理結果」「返ってきた形式」「ブラウザに保存させる情報」「次に見るべき本文」の順に確認すると整理しやすくなります。
ステータスコードの一覧を暗記する記事ではありません。実際の調査で、どの部分を見るべきかを練習します。
レスポンス全体の形
HTTPレスポンスは、主に3つの部分でできています。
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Cache-Control: no-store
Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax
{"id":1,"name":"Ada"}
| 部分 | 見ること |
|---|---|
| ステータスライン | 成功か失敗か |
| ヘッダー | 形式、キャッシュ、Cookie、リダイレクトなど |
| ボディ | HTML、JSON、画像、エラー詳細など |
まずはステータスコードを見ます。その後、Content-Type、Location、Set-Cookie、Cache-Control、本文を確認します。
Step 1: ステータスコードを見る
先頭の HTTP/1.1 200 OK のうち、200 がステータスコードです。
HTTP/1.1 404 Not Found
大まかな分類は次の通りです。
| 範囲 | 意味 |
|---|---|
2xx | 成功 |
3xx | リダイレクト |
4xx | クライアント側のリクエストに問題がある |
5xx | サーバー側で処理に失敗した |
最初に見るのはこの分類です。404 ならURLやルーティング、401 ならログイン状態、500 ならサーバーログや例外、というように調査の方向が決まります。
Step 2: Content-Typeを見る
Content-Type は、レスポンス本文の形式を表します。
Content-Type: application/json; charset=utf-8
| 値 | 返ってくるもの |
|---|---|
text/html | HTMLページ |
application/json | JSON |
text/css | CSS |
application/javascript | JavaScript |
image/png / image/webp | 画像 |
application/pdf |
APIのつもりで呼んだのに text/html が返っている場合、ログイン画面、エラーページ、404ページなどが返っていることがあります。フロント側で Unexpected token < in JSON のようなエラーが出るときは、JSONではなくHTMLをJSONとして読もうとしているケースが多いです。
Step 3: Locationを見る
3xx のレスポンスでは、Location ヘッダーを確認します。
HTTP/1.1 302 Found
Location: /login
これは「次は /login を見てください」という意味です。
よくある読み方:
| 状態 | 読み取り |
|---|---|
/login に飛ばされる | 未ログイン扱いになっている |
http から https に飛ぶ | HTTPSへ正規化している |
| 旧URLから新URLへ飛ぶ | リダイレクト設定がある |
| 何度も同じ場所へ飛ぶ | リダイレクトループの可能性 |
ブラウザはリダイレクトを自動で追うため、最終的な画面だけ見ていると途中の 302 を見落とします。DevToolsのNetworkで最初のリクエストから順番に見ます。
Step 4: Set-Cookieを見る
ログインやセッション更新では、レスポンスに Set-Cookie が含まれることがあります。
Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax; Path=/
見るポイントは次の通りです。
| 属性 | 確認すること |
|---|---|
HttpOnly | JavaScriptから読ませない設定か |
Secure | HTTPS通信でのみ送る設定か |
SameSite | 外部サイトからの送信制限 |
Path | Cookieを送るパス範囲 |
Domain | Cookieを送るドメイン範囲 |
Expires / Max-Age | 有効期限 |
ログイン成功レスポンスに Set-Cookie があるのに次の画面で未ログインになる場合、Cookieが保存されていない、次のリクエストで送られていない、ドメインやSameSiteの条件に合っていない、などを確認します。
Step 5: Cache-Controlを見る
Cache-Control は、ブラウザやCDNにキャッシュの扱いを伝えます。
Cache-Control: public, max-age=31536000, immutable
| 値 | 読み方 |
|---|---|
no-store | 保存しない |
no-cache | 再利用前に確認する |
max-age=60 | 60秒間は新鮮として扱う |
public | 共有キャッシュも保存できる |
private | 個人向けなので共有キャッシュは避ける |
immutable | 内容が変わらない前提で強くキャッシュ |
CSSや画像が更新されない場合は、キャッシュが効いている可能性があります。逆に、ログイン後の個人情報ページが強くキャッシュされている場合は、セキュリティやプライバシー上の問題になります。
Step 6: ボディを見る
レスポンスボディには、実際の本文が入ります。
JSON APIなら次のような形です。
{
"error": "validation_failed",
"message": "email is required"
}
画面用ページならHTMLです。
<!doctype html>
<html lang="ja">
<head>
<title>ログイン</title>
</head>
<body>...</body>
</html>
APIエラーでは、ステータスコードだけでなく本文のエラーコードやメッセージを確認します。400 Bad Request でも、本文に「どの項目が足りないか」が書かれていることがあります。
読み方の練習
次のレスポンスを読んでみます。
HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/users/42
{"id":42,"name":"Ada"}
読み取り:
| 項目 | 内容 |
|---|---|
| 結果 | 作成成功 |
| 形式 | JSON |
| 作成された場所 | /api/users/42 |
| 本文 | 作成されたユーザー情報 |
201 Created は、作成処理が成功したときによく使われます。Location がある場合、作成されたリソースの場所を示します。
次の例も見ます。
HTTP/1.1 401 Unauthorized
Content-Type: application/json
WWW-Authenticate: Bearer
{"message":"token expired"}
読み取り:
| 項目 | 内容 |
|---|---|
| 結果 | 認証が必要、または認証に失敗 |
| 認証方式 | Bearer Token |
| 失敗理由 | トークン期限切れ |
この場合、URLやサーバー停止ではなく、ログイン状態やトークン更新処理を見るべきです。
DevToolsで見る場所
Chrome DevToolsでは、Networkパネルで対象の通信を選びます。
| 見たいもの | 場所 |
|---|---|
| ステータスコード | Headers > General |
| レスポンスヘッダー | Headers > Response Headers |
| JSON本文 | Preview または Response |
| HTML本文 | Response |
| Cookie保存 | Application > Cookies |
| キャッシュ状態 | NetworkのSize列、Headers |
API通信だけを見たい場合は、Networkパネルの Fetch/XHR フィルターを使うと探しやすくなります。
curlで確認する
ヘッダーだけを見る場合は、次のようにします。
curl -I https://example.com
リダイレクトも追う場合:
curl -I -L https://example.com
本文も含めて詳細に見る場合:
curl -v https://example.com
ブラウザとcurlで結果が違う場合、Cookie、CORS、キャッシュ、ユーザーエージェント、認証ヘッダーの違いを確認します。
まとめ
HTTPレスポンスは、ステータスコード、Content-Type、Location、Set-Cookie、Cache-Control、本文の順に見ると原因を切り分けやすくなります。
画面に出ているエラーだけで判断せず、実際に返ってきたステータスとヘッダーを見ることが、Webアプリの不具合調査の基本です。
