緑の札には、たしかに 200 と書かれていた。
受付の鐘も鳴った。
けれど、返ってきたのは夕焼けの続きではない。
青い入口と、三つの案内ボタンだけのページだった。
イトは、空になった一枚目のリクエスト券を握った。
残りは一枚。時計は四十秒。
イト
成功って出たのに、どうして見たい場面じゃないの？
ピコ
その200は、イトが頼んだことには成功しているよ
イト
頼んだこと……？
机の上には、イトが送った一通目が残っていた。
GET /
DNSで見つけた練習サーバーへ、イトが選んだのは一番短い入口だった。
サーバーは、その入口のページを正しく返したのだ。
HTTPは、宛先の先で「何をするか」を伝える
第5話で、イトは video.blue.example. に結びつく宛先を確かめた。
けれど、同じサーバーにも入口、各話、画像、見た目のルールなど、別々の対象がある。
HTTPでは、どんな操作をしたいかを メソッド で、どの対象へ行うかを リクエストターゲット で伝える。
今回の GET は、対象の表現を受け取りたいというメソッドだ。
最初の / は、サーバーの入口を指すターゲットだった。
RFC 9110は、HTTPをリソースに対してメソッドを適用する仕組みとして定め、GETを対象リソースの現在選ばれた表現を転送してもらうメソッドとして説明している。
ユイ
サーバーの住所が合っていても、その中のどれを頼むかは別なんですね
マコト
図書館へ着いただけでは、読みたい本を頼んだことにならないのと似ているね
ピコ
そう。ただし本物のHTTPメッセージは手紙そのものではない。封筒は、この街で順番を見えるようにした模型だよ
リクエストとレスポンスに入るもの
ピコが一通目を、左右に開いた。
左はブラウザからサーバーへ進む リクエスト。
右はサーバーから戻る レスポンス。
| メッセージ | 中心になるもの | 今回の例 |
|---|---|---|
| リクエスト | メソッド、対象、追加条件を伝えるフィールド、必要な場合の内容 | GET、/ |
| レスポンス | ステータスコード、説明用のフィールド、返す内容 | 200、Content-Type: text/html、入口ページのHTML |
フィールドは、扱えるデータ形式や認証などの追加情報を運ぶことがある。
内容は、メッセージに本文が必要な場合に使う。すべてのリクエストとレスポンスに必ず入るわけではない。
HTTP/1.1ではリクエスト行やヘッダーフィールドとして見える部分も、HTTP/2やHTTP/3では通信路上の表し方が異なる。この物語はバイト列の姿ではなく、バージョンをまたいで考えられる役割を模型にしている。
RFC 9110はHTTPメッセージを、制御情報、フィールド、内容などに分ける。RFC 9112はHTTP/1.1メッセージの行や転送方法を定めている。
イトは、一通目のレスポンスを裏返した。
- ステータス:
200 OK - フィールド:
Content-Type: text/html - 内容: 入口ページのHTML
壊れた返事ではない。
サーバーは、GET /に対して入口ページを返す仕事を終えている。
200は「あなたが心の中で欲しかったもの」の証明ではなく、そのリクエストが成功したという返事だ。
残り一枚で、何を頼む？
入口ページの中から、二つの道が浮かび上がった。
一つは、夕焼けの静止画。
/images/sunset.avif
もう一つは、台詞と場面の順番を含む続きのページ。
/episodes/last-scene
残り三十秒。
案内台に、三つの選択が現れた。
- 200が出たので、入口ページで成功とする
- 夕焼け画像だけをGETする
- 続きのページを示す対象へGETを送る
二つ目なら、見覚えのある夕焼けは手に入る。
けれどイトが知りたいのは、主人公が振り返ったあとに何を言うかだ。
画像だけでは、台詞も場面の順番も分からない。
三つ目は、残った一枚を使う。
対象をまた間違えれば、今日はやり直せない。
ピコは答えを言わず、二枚の札を照らした。
イトは、入口ページの200札を机へ置いた。
「ぼくが欲しいのは、夕焼けの絵だけじゃない」
続きのページに付いた案内を、一文字ずつ確かめる。
「台詞まで入った、このページ」
イトは最後の券に GET /episodes/last-scene を組み、送信台へ差し込んだ。
二枚目の200は、同じ数字で違う中身だった
残り十八秒。
サーバーの受付が、対象を読み取った。
残り十一秒。
青いレスポンスが戻ってくる。
その表にも、同じ 200 が光っていた。
けれど、フィールドと内容は違う。
- ステータス:
200 OK - フィールド:
Content-Type: text/html - 内容: 続きのページを表すHTML
材料読取台に、探していた一行が現れた。
「夕焼けのあとで、主人公は振り返った。」
その下には、台詞の続きと、夕焼け画像への参照、見た目のルールへの参照が並んでいる。
イトは、二枚の200を横に置いた。
最初は入口ページへの成功。
二枚目は続きのページへの成功。
数字が同じでも、選んだ対象が違えば、返る表現も違う。
イト
200だけじゃなくて、何を頼んだ返事かを見るんだ
ピコ
うん。ステータス、フィールド、内容をリクエストと組にして見る
ユイ
エラーの番号だけでなく、成功の番号も中身と目的を確かめる必要があるんですね
時計がゼロになった。
HTMLが届いても、夕焼けはまだ描かれない
正しいページのHTMLは届いた。
それでも画面は、白い骨組みのままだった。
台詞の場所。
画像を置く四角。
見た目のルールを結びつける印。
材料の参照は読めるが、夕焼けの色はない。
HTMLに画像やスタイルシートなど別のリソースへの参照があれば、ブラウザはそれらも取得する必要がある。すでに手元にある場合やページの作りによって動きは変わるが、一回のレスポンスだけで必要な材料がすべて入るとは限らない。
WHATWG HTML Living Standardは、img要素やスタイルシートを示すlink要素などが指すリソースを取得し、文書へ結びつける処理を定めている。
イトの足元で、使い終えた二枚の券が透明になった。
一枚目を使わなければ、もっと早かった。
けれど、一枚目が正しく失敗したわけではないことも分かった。
間違っていたのはレスポンスではなく、イトが最初に選んだ対象と、自分の目的のずれだった。
「材料は合ってる。でも、まだ場面になってない」
イトがHTMLの設計図を持ち上げる。
画像の四角から、夕焼け色の光が細く漏れた。
その光の先で、ブラウザ工房の歯車が回り始める。
次回：材料はどう画面になる？
HTTPのリクエストでは、何をするかと、どのリソースへ行うかを伝える。
レスポンスのステータスはリクエストの結果を示し、フィールドと内容が返事の条件や中身を運ぶ。
200だけで終わらず、選んだ対象と返った内容が目的に合うかを確かめる。
次回、ピコルート第7話。
材料はどう画面になる？
HTTPの基本を図でも整理するなら、HTTPとはへ進めます。