HTTP/1.1
目次
Pegasus は Plan9 第3版の標準 httpd をベースに開発されました。従って標準 httpd の HTTP/1.1 の仕様を継承しています。
URI redirection
サーバに対するクライアントからのリクエストは本質的にはファイルの要求です。HTTP/1.1 のサーバは、クライアントからリクエストされたファイルに対して、他のファイルや URI をクライアントに紹介するメカニズムを持っています。
例えば URI
http://plan9.aichi-u.ac.jp/pegasusについて考えてみましょう。この URI は正しくはありません。なぜなら
http://plan9.aichi-u.ac.jp/pegasus/が正しい URI です。(が多くの人はスラッシュを付けないでしょう)
クライアントが
http://plan9.aichi-u.ac.jp/pegasus/index.htmlに記述されているファイルやディレクトリのパスを誤解します。例えばこの
http://plan9.aichi-u.ac.jp/man-1.0/であると誤解するのです。(従ってアクセスに失敗するでしょう)
HTTP/1.1 はこの問題を URI redirection によって解決しています。即ちディレクトリ名に対してスラッシュで閉じないでリクエストされた場合にはサーバはスラッシュを付けて再度要求する様にクライアントに伝えます。クライアントは自動的に正しい URI を再送信します。
URI redirection に関する他の応用はホームページが移動した場合の処理です。サーバは自動的に新しいホームページにクライアントを誘導できます。(この設定は rewrite ファイルで行います。)
Pegasus は URI redirection を Pegasus 内部のレベル、管理者レベル、ユーザレベルでサポートしています。
仮想ホスト
仮想ホストは HTTP/1.1 でサポートされました。これによって1つのホストが1つの IPアドレスで複数のドメイン名を持つ事ができるようになりました。
ブラウザを使用してホスト
http://ar.aichi-u.ac.jpと書きます。するとブラウザはホスト ar.aichi-u.ac.jp のポート 80 に
GET / HTTP/1.1 User-Agent: .... Host: ar.aichi-u.ac.jp ...のようなメッセージを送ります。
ここに現れる
Pegasus は仮想ホストをサポートしています。しかも仮想ホスト毎に独立した名前空間を提供しています。
持続的接続(persistent connection)
HTTP/1.1 からは持続的接続が接続方式の基本となりました。持続的接続はサーバあるいはクライアントの一方が接続を閉じた時に終了します。
Pegasus は、通常のファイル転送に関しては持続的接続を続行します。CGI については、持続的接続の継続と解消を制御できます。
持続的接続の問題は運用上難しいものがあります。サーバがおっとりしていると攻撃の対象になりかねません。(だから筆者は、用が済めばさっさと切りたい。) どのタイミングで切れば良いのか、判断に迷っています。
CGI で持続的接続を行う場合には、サーバは CGI の出力を全て一旦受け取る事になります。(なぜなら Content-Length をクライアントに伝えなくてはなりません。) CGI プログラムがバックグランドジョブを流した場合に、そのジョブが終るまでサーバは待たされる事になります。(Webメールの場合にそのような問題が発生する。)
かような訳で現在は思案中…
アクセスメソッド
Pegasus は- GET
- HEAD
- POST
- OPTIONS
- PUT
- DELETE
- TRACE
PUT と DELETE は Netscape 7.0 は対応しています。Netscape 7.0 は、ブラウザを使用してサーバの HTML コードを編集できるようにしています。便利なのですが、これらのサポートするにはセキュリティには十分に配慮しなければなりません。現在の基本認証では PUT や DELETE は危なくてサポートの意欲が消えます。