総合演習 — HTTP の会話をケースで読み解く
実務の障害調査を模した 8 つのケースに、「何を頼んだか・結果はどうだったか・条件と補足」の 3 点セット読みを当てて、全 6 章の知識を横断して使う。
仕上げの 8 問 — ケースに 3 点セットを当てる
最終章は総合演習です。実務で出会う場面を模した 8 つのケースに、全 6 章の知識を横断して答えます。迷ったら、この講座の合言葉に立ち返ってください — 何を頼んだか？ 結果はどうだったか？ 条件と補足は何か？
| つまずいたら | 戻る章 |
|---|---|
| メッセージの骨格・ステートレス | 第 1 章 |
| メソッドの使い分け・安全と冪等・リトライ | 第 2 章 |
| ステータスコードの分類と切り分け | 第 3 章 |
| Host・Content-Type・Cookie などのヘッダ | 第 4 章 |
| max-age・ETag・304・no-store | 第 5 章 |
| curl と Network タブの観察手順 | 第 6 章 |
ケース調査の型です。症状から出発し、リクエスト行（何を頼んだか）→ ステータスコード（結果はどうだったか）→ ヘッダ（条件と補足）の順に読むと、原因の側（クライアント側 / 転送 / サーバ側 / キャッシュ）が絞り込めます。
ケース 7-1 — リダイレクトとフォームのトラブル
第 2〜3 章と第 6 章の範囲です。転送の連鎖と、POST の再送を読み解きます。
Q1. ケース: https://example.com/mypage を開くとブラウザが「リダイレクトが繰り返し行われました」というエラーを表示します。curl -v https://example.com/mypage で観察すると、302 で Location: /login へ、/login も 302 で Location: /mypage へ転送していました。起きていることの説明として正しいものはどれですか。
Location の行き先を辿ると /mypage → /login → /mypage の循環が見えます。典型的な原因は、ログイン判定の条件（Cookie の有無など）が 2 つのページで食い違い、互いに相手へ転送し合うことです。ブラウザは一定回数で打ち切ってこのエラーを出します。503 なら Status にそう出ますし、DNS が壊れていればそもそも接続できません。curl はループを 1 段ずつ正直に見せてくれた側です。
Q2. ケース: 注文完了ページでブラウザを再読み込みした利用者から「フォーム再送信の確認が出て、進むと注文が二重になった」と報告がありました。サーバ側の定番の対策はどれですか。
POST への 200 応答をそのまま表示すると、再読み込み = POST の再実行になります（POST は冪等ではないので二重注文になり得る — 第 2 章）。POST/Redirect/GET は、処理後にリダイレクトを返して完了ページを GET で見せる型で、再読み込みされても安全な GET が繰り返されるだけになります。no-store は再送信問題を解決せず、注文を GET にするのは「安全なメソッドで状態を変える」逆方向の悪手です。
Q3. ケース: 画像ファイルのレスポンスヘッダに Cache-Control: max-age=604800 が設定されています。このキャッシュが fresh でいられる期間は何日ですか。
604800 ÷ 86400（1 日の秒数）= 7 日です。第 5 章の頻出値の換算そのものです。「1 週間キャッシュしてよい」という設定は静的ファイルでよく見かけるので、604800 を見た瞬間に 7 日と読めると設定レビューが速くなります。
ケース 7-2 — 反映されない・化ける・見えない
第 3〜6 章の範囲です。キャッシュ・権限・文字コードを切り分けます。
Q4. ケース: CSS を修正してサーバに反映したのに、自分のブラウザでは古いデザインのまま表示されます。Network タブを見ると、その CSS の行の Size 列に (disk cache) と表示されていました。原因と対処の組み合わせとして最も適切なものはどれですか。
(disk cache) は「サーバにリクエストが飛んでいない」の決定的な目印です（第 5〜6 章）。サーバをいくら直しても、fresh の間ブラウザは見に来ません。手元の確認は Disable cache で十分ですが、利用者全員のキャッシュは消せないので、恒久対策は style.v2.css のように URL 自体を変えて「別のリソース」として取得させる設計が定番です。アップロード失敗なら Size 列に通常の転送量が出ているはずです。
Q5. ケース: 会員制サイトで、ログイン済みの利用者から「昨日まで見られた資料ページが今日から見られない」と報告がありました。Network タブではそのページへの GET が 403 を返しています。この観察から言えることとして最も適切なものはどれですか。
403 は「誰かは分かったが、権限がない」（第 3 章）。削除なら 404、サーバダウンなら 5xx や接続エラーになるはずで、403 が返っている時点でサーバは生きていてリクエストも届いています。「昨日まで見られた」と合わせると、資料の公開範囲や会員種別・権限設定が変わった可能性が高い、と調査先が絞れます。ステータスコード 1 つで、疑う場所がここまで変わります。
Q6. ケース: リニューアルした https://example.com のページで日本語が「è±�å�」のような記号列に化けています。curl -I で確認すると Content-Type: text/html; charset=ISO-8859-1 が返っており、HTML ファイル自体は UTF-8 で保存されていました。適切な対処はどれですか。
実体は UTF-8、ラベルは ISO-8859-1 — 第 4 章で読んだ「ラベルと中身の不一致」そのものです。ブラウザは宣言を信じて誤った文字コードでバイト列を解釈するため化けます。直すべきはサーバの charset 宣言で、利用者に毎回の設定変更を強いる案や、本文を英語・画像にする案は原因を放置した回避策にすらなっていません。ヘッダを直せば全員の表示が一度に直ります。
ケース 7-3 — 障害の切り分けとリトライの判断
第 2〜3 章の総仕上げです。5xx の切り分けと、冪等性にもとづくリトライ判断で講座を締めくくります。
Q7. ケース: サイト全体が突然エラーになり、どの URL でも 502 Bad Gateway が返ります。構成は「リバースプロキシ + 後ろのアプリケーションサーバ」の 2 段です。最初に調べる場所として最も適切なのはどれですか。
502 は「中継役は生きているが、後ろから正常な応答を得られなかった」（第 3 章）。502 という HTTP レスポンスが返ってきていること自体が、プロキシまでは到達できている証拠です。だから初手はアプリケーションサーバの死活とログ。ブラウザ設定や DNS 契約が原因なら、そもそも 502 という形の返事は届きません。3 桁の数字が、2 段構成のどちら側かまで教えてくれています。
Q8. ケース: 在庫管理システムで 2 つのリクエストがタイムアウトしました。(A) PUT /items/42（商品 42 の情報をこの内容に置き換える）と (B) POST /orders（新規発注を作成する）です。機械的にすぐ再送してよいのはどちらですか。
講座の締めくくりは第 2 章の実務感覚です。タイムアウトは「処理されたのに返事だけ失われた」可能性を含みます。PUT は同じ内容への置き換えなので、仮に 2 回処理されても最終状態は同じ — 安心して再送できます。POST は 2 回処理されれば発注が 2 件。確認や重複防止の仕組みなしの再送は事故です。「更新のリトライは冪等性を確認してから」— この一文を持ち帰ってください。
講座の終わりに — 往復書簡の読み方を持ち歩く
お疲れさまでした。この講座で暗記した項目は、実はごくわずかです。代わりに持ち帰ってほしいのは、どんな出力の前でも通用する読み方の型です。
- 何を頼んだか — リクエスト行のメソッドとパス。その頼みごとは安全か、冪等か
- 結果はどうだったか — ステータスコードを百の位から。誰の問題かがまず分かる
- 条件と補足は何か — Content-Type は中身と一致しているか。Cache-Control は何を約束しているか。Cookie は添えられているか
開発者ツールの Network タブも、curl -v の出力も、明日から出会うどんな HTTP のログも、この 3 点で必ず読み始められます。圧倒されずに、いつもの 3 点から読む — それがこの講座で身につけた力です。