HTTP の基本

「画面が真っ白です」と言われて、どこから見るか

不具合の報告が来たとき、最初に知りたいのは「ブラウザが何を送って、サーバーが何を返したか」です。ここが読めないと、直すのが自分なのか相手なのかも決められません。ブラウザとサーバーの間を流れているのは、実はただのテキストです。

送るほうは 1 行目で用件が決まる

ブラウザが送るリクエストは、用件を書いた 1 行目、付帯情報を並べたヘッダー、そして本文の 3 つでできています。

1 行目の GET /articles/network が「この住所のものをください」という用件です。ヘッダーはそこに付ける但し書きで、Host はどのドメイン宛てかを示します。ページを取りに行くだけなら本文は空のままです。

返すほうも 1 行目で結果が決まる

サーバーの返事も同じ形です。1 行目に結果、続いてヘッダー、そして本文が入ります。

200 が結果を表す 3 桁の数字です。この数字は暗記するものではなく、桁で読みます。200 番台は成功、300 番台は場所が移ったという知らせ、400 番台は依頼した側の間違い、500 番台は受けた側の故障です。

つまり 404 が返っているなら、押しているリンクや叩いている URL のほうを疑います。500 が返っているなら、こちらの送り方は届いていて、サーバーの中で処理が転んでいます。1 桁目を見るだけで、調べる場所が半分に絞れます。

この 2 つのかたまりは、ブラウザの開発者ツールの Network パネルでそのまま読めます。手元から直接見たいときは、レスポンスのヘッダーまで表示する指定を付けて取得します。

不具合の報告を受けたら、まずここを見ます。何を送って何が返ったかが分かれば、話は「誰の担当か」から「どこを直すか」に変わります。

サーバーは前回の話を覚えていない

HTTP はリクエストを 1 つずつ独立に扱います。さっきログインした人からの 2 回目でも、サーバーは何も覚えていません。

覚えていないのに、ログイン状態が続くのはなぜか。クライアント側に保存した Cookie やトークンを、毎回のリクエストにくっつけて送り直しているからです。状態はサーバーではなく、送られてくる紙のほうに書いてあります。

裏を返すと、そこに入れたものは全部、画像 1 枚を取るリクエストにまで付いてきます。Cookie を安易に増やすと、以降のすべての通信が少しずつ重くなります。

解説

現場の話

覚えないのは不便に見えて、実は台数を増やせる理由になっています。どのサーバーが受け取っても判断材料が全部リクエストに入っているので、前段で好きに振り分けられます。アクセスが増えたらサーバーを足すだけで捌ける設計は、この性質の上に成り立っています。