要約

  • RFC 1866は、HTMLの作者が名前と値の入力を集め、宣言したアクションとメソッドでサービスへ送る共通の方法を示した。
  • ブラウザーはリクエストを組み立てられたが、サービスの判断をHTMLが決めるわけではなく、要求した処理の完了も証明しなかった。

ページは行き先だけではなくなった

リンクは別のリソースへの道を示す。フォームは文書の値を利用者が変更し、遠隔サービスに処理を求める道を加えた。1995年11月のRFC 1866は、フォームをデータのひな型とメソッド、アクションURIの組み合わせと定義した。データは名前と値の組で、ブラウザーが入力や選択を集め、アクションが宛先、メソッドが送信方法を示す。

当時これは、文書閲覧からネットワークサービス利用へ進む一歩だった。検索、アンケート、申込み、予約をサイト別の専用クライアントなしでページに置ける。規格が揃えたのはブラウザーとサービス間のリクエスト形式で、サービス内部の処理ではない。

1994年7月11日、Paul Burchardは改訂したFORM仕様をDaniel Connollyに送り、アクションURL、メソッド、エンコード、名前と値の組を定義した。要求するアクセスプロトコルはHTTPで、既定値はGET、多くの用途にはPOSTが向くとした。10日後、Connollyは最終審査段階を知らせ、HTMLを入力すると提案DTDの解析結果を返す対話式検証サービスを紹介した。これは審査中の利用例で、普及率ではない。7月のIETF議事録も標準化課題にフォームを挙げている。

RFC 1866は非公式に使われていた機能をまとめ、Level 2ユーザーエージェントに入力と送信を勧告した。適合性への期待であり、全ブラウザーが全要素を実装した証拠ではない。フォームの先のアプリ動作を共通化するものでもなく、ブラウザー側の交換形式とリクエスト構築を揃えた。

GETでは値をエンコードしてアクションURIに加え、リンクのようにたどる。RFCは、繰り返しても永続的な変化を残さない冪等な処理にGETを勧め、検索を例にした。URIは保存・共有できる。一方、長いURIを当時の一部サーバーが正しく扱えないこと、GETが永続的な副作用を起こすべきでないことを警告した。データベース変更や登録にはPOSTを勧め、値を本文に入れて応答を表示する。

どちらの方法もサーバーの動作を決めない。GETの無作用性はサービス次第で、POSTも取引や結果を保証しない。検証と効果はサーバーに残る。基本仕様にはファイル送信もなかった。同月のRFC 1867はINPUT TYPE=FILE、ACCEPT、multipart/form-dataを提案したが、明示的にExperimentalだった。

フォームだけでWebアプリが生まれたのではない。HTTPにはメソッドがあり、サーバーはリクエストを処理していた。限定して言えるのは、HTMLが利用者の値をリクエストに含める宣言的な方法と共通の構築規則を提供したことだ。ページの問い、ブラウザーの送信、サービスの判断は別々に残った。

Sources