Summary

  • 1991年のWeb初期実装を記したHTTPの説明では、クライアントの単一のGET要求にHTML文書が返り、サーバーが接続を閉じて文書の終わりを示した。
  • この簡潔なやり取りにはステータス行もヘッダーもなかった。当時の設計メモは、エラーも文書として返り、文章を読まない限り成功と区別できないと記している。
  • 後のHTTPはバージョン、ヘッダー、ステータスコードを加えながら、互換性のために単純な形式を残した。その継承はHTTP/0.9の普及規模を示すものではない。

ページが応答のすべてだった

1991年のWorld Wide Web実装説明では、クライアントはサーバーへ接続し、アドレスにポートがなければ80番を使う。その後、文書識別子を含むGETの一行を送る。サーバーはHTMLのバイト列を返し、文書を送り終えると接続を閉じる。ページの前に独立したステータス行はなく、その後にもヘッダーのまとまりはない。受信した最初のバイトからすでに文書の一部だった。

Tim Berners-Leeの実装記録は、各ページを包む見えないHTTPの封筒を説明してはいない。応答をHTMLのメッセージとし、接続を閉じることで転送が終わると記す。また、サーバーは人が読めるエラー文をHTMLで返せる。そこで明記された代償は、エラー応答と正常な応答を区別する方法が本文の文章しかないことだった。ブラウザーは届いたものを表示できるが、形式上は「見つからない」「転送先が変わった」「サーバー障害」といった機械可読のコードを得られない。

1992年6月の概要は、この交換の設計上の割り切りを示す。ブラウザーが送る命令はGETだけで、名前付きインデックスを指す場合は文書識別子に検索語を加えられた。サーバーはブラウザーについて状態を保持しない。応答はHTMLでもプレーンテキストでもよく、文書だけでなくメニューや検索結果一覧も載せられた。サーバーから出るものがマークアップされたテキストだけという単純さは利点だった。一方、HTTP情報、文書の内容、文書の種類のあいだに字句上の境界がないと指摘した。エラーも文書であり、読者が見落とす可能性があった。

この曖昧さはメッセージ形式の性質であり、初期サーバーで障害が頻発したことや、人がエラーを読めなかったことを意味しない。人間は本文を解釈できても、プログラムには調べるステータス欄がない。接続の終了は、文書が正常に終わった場合にも、途中で交換が止まった場合にも使われた。流れが止まったことは分かるが、理由は分からない。

初期設計は静的ページだけに限られてもいなかった。ISINDEX要素があれば、ブラウザーは文書識別子にキーワードを付けて検索要求を作ることができ、サーバーはHTMLの結果一覧を返せた。Berners-Leeの「なぜ新しいプロトコルが必要か」という説明は、インデックス検索、自動形式交渉、別サーバーへの案内も情報アクセスに必要な機能として挙げる。ただし、これらはより広い設計目標であって、一行の単純な交換にすべて備わっていたという証拠ではない。

本文の外に応答情報を加える

1992年12月の公開www-talkメールには、プロトコルを広げる提案が残る。Berners-Leeは、新しいサーバーも既存のGET <url>を認識し続けるべきだとした。そのうえでクライアントは同じ行にバージョン識別子を加え、From、Accept、Accept-Encodingなどのヘッダーを続けられる。例の応答にはバージョン、応答フィールド、MIMEコンテンツ型、許可メソッドが登場する。これは議論中の提案で、実際に展開された最終形式の記録ではない。それでも、応答には本文だけでなく自身についての情報も必要になるという問題意識を示す。

1996年のInformational RFC 1945は、後に二つの形式を記述した。単純な要求はヘッダーのないGETとURI、単純な応答は本文だけでサーバーの接続終了により終わる。完全な応答はステータス行から始まり、応答ヘッダーやエンティティヘッダーを持てる。RFCは単純な要求では返すメディア種別をサーバーが特定できないと注意する。旧形式を認識可能なままにしておけば、後のHTTPシステムは以前のクライアントやサーバーを考慮しつつ、同じメッセージ形式を送っているふりをせずに済む。

時系列の区別も大切だ。RFCの遡及的な定義は互換性を理解する助けになるが、1991年にHTTP/0.9という独立標準が批准された証拠ではない。Berners-Leeは後年、Nicola Pellowのラインモード・ブラウザーを含む最初のWebサーバーとクライアントが、1991年夏に高エネルギー物理学のコミュニティ、その後ハイパーテキストとNeXTのコミュニティへ公開されたと振り返った。URI、HTML、HTTPの仕様も議論と採用を促すため最初のサーバーに置かれたという。この記録は実験の背景を示すが、各形式の利用数は示さない。

文書だけを返す方式なら、資源を求めてブラウザーが表示できる内容を受け取るという仕組みは分かりやすい。応答をプロトコル上の出来事として扱うと、限界が表面化した。ステータス行がないと、HTMLのエラーもページも同じ位置を占める。後のHTTPメッセージは結果、メタデータ、表現を分けた一方、単純な形式も互換用に残った。

出典