付録 E   HTTP (HyperText Transfer Protocol)


ハイパーテキスト転送プロトコル (HyperText Transfer Protocol: HTTP) は、Webブラウザなどのクライアントと Web サーバが、互いに通信するためのプロトコル (情報の交換方法を記述した規則のセット) です。

HTTP は、要求/応答モデルに基づいています。 ブラウザはサーバへの接続を開いて、サーバに要求を送信します。

サーバは、要求を処理して、ブラウザに送信する応答を生成します。 その後、サーバは接続を閉じます。

この付録では、HTTP の基礎のいくつかについて簡単に説明します。 HTTP についての詳細は、次の場所にある IETF のホームページを参照してください。

http://www.ietf.org/home.html

この付録では次の節について説明します。

• 準拠

• 要求

• 応答

• バッファ化されたストリーム

準拠

---

iPlanet Web Server 6.0 は HTTP 1.1 をサポートします。 以前のバージョンのサーバも HTTP 1.0 をサポートしていました。 このサーバは、IESG (Internet Engineering Steering Group) および IETF (Internet Engineering Task Force) の HTTP ワーキンググループ承認の HTTP 1.1 規格案に、条件付きで準拠しています。

条件付き準拠の基準については、次の場所にある「Hypertext Transfer Protocol--HTTP/1.1 specification (RFC 2068)」を参照してください。

http://www.ietf.org/rfc/rfc2068.txt?number=2068

要求

---

ブラウザからサーバへの要求には、次のような情報が含まれています。

• 要求メソッド、URI、およびプロトコルのバージョン

• 要求ヘッダー

• 要求データ

要求メソッド、URI、およびプロトコルのバージョン

ブラウザは、多数のメソッドを使って情報を要求することができます。 一般的に使われるメソッドには、次のものがあります。

• GET 指定したリソース (ドキュメントやイメージなど) を要求します

• HEAD ドキュメントのヘッダー情報のみを要求します

• POST CGI プログラムが処理するためのフォームからの入力など、サーバが受け入れるデータをブラウザに要求します

• PUT サーバのドキュメントの内容を、ブラウザからのデータで置き換えます

要求ヘッダー

ブラウザはサーバにヘッダーを送信できます。 ただし、ほとんどのものは任意 (省略可能) です。 一般的に使われる要求ヘッダーのいくつかを、表 E-1に示します。

表 E-1 一般的な要求ヘッダー 

要求ヘッダー	説明
Accept	ブラウザが受け入れ可能なファイルタイプ
Authorization	ブラウザがサーバで自身を認証したい場合に使われます。ユーザ名やパスワードなどの情報が含まれます
User-agent	ブラウザソフトウェアの名前とバージョン
Referer	ユーザがリンクをクリックしたドキュメントの URL
Host	要求されているリソースのインターネットホストとポート番号

要求データ

ブラウザは、POST または PUT 要求を実行した場合、要求ヘッダーに続く空白行の後にデータを送信します。 ブラウザが GET または HEAD 要求を送信した場合は、送信するデータはありません。

応答

---

サーバの応答には次のものが含まれます。

• HTTP プロトコルのバージョン、状態コード、および原因を示す文字列

• 応答ヘッダー

• 応答データ

HTTP プロトコルのバージョン、状態コード、および原因を示す文字列

サーバは状態コードを返信します。状態コードは 3 桁の数値コードです。 状態コードには、次の 5 つのカテゴリがあります。

• 100 〜 199 は、暫定的な応答です。

• 200 〜 299 は、成功したトランザクションです。

• 300 〜 399 は、要求されたリソースは別の場所で検索する必要があることを示します。

• 400 〜 499 は、ブラウザの原因によるエラーが発生したことを示します。

• 500 〜 599 は、サーバで重大なエラーが発生したことを示します。

いくつかの一般的な状態コードを表 E-2に示します。

表 E-2 一般的な HTTP 状態コード 

状態コード	意味
200	OK。使用したメソッド (GET、POST、HEAD) に対する要求が成功しました。
201	要求によって、返された URI による新しいリソース参照が作成されました。
206	サーバがバイト範囲要求に応答を送信しました。
302	見つかりました。 新しい URL へ、リダイレクトします。 元の URL は移動しました。 これはエラーではありません。ほとんどのブラウザでは、新しいページを取得できます。
304	ローカルコピーを使用します。 ブラウザのキャッシュにすでにページがあり、そのページが再度要求されている場合、ブラウザ (Netscape Navigator など) の種類によっては、ブラウザのキャッシュされたコピーにある「最終更新の (last-modified)」タイムスタンプを Web サーバに中継することがあります。 このサーバ上のコピーがブラウザのコピーよりも古い場合、サーバは、不要なネットワークトラフィックを減らすために、そのページを返すのではなく 304 コードを返します。 これはエラーではありません。
400	要求が、有効な HTTP/1.0 または HTTP/1.1 要求でない場合に送信されます。 たとえば、HTTP/1.1 では、ホストを「Host」ヘッダー内または要求行の URI の一部として指定する必要があります。
401	承認されていません。 ユーザがドキュメントを要求しましたが、有効なユーザ名およびパスワードが指定されていませんでした。
403	禁止。 この URL へのアクセスは禁止されています。
404	見つかりませんでした。 要求されたドキュメントがサーバ上にありません。 このコードは、承認されていないユーザにドキュメントが存在しないと伝えることによって、サーバがドキュメントを保護するよう指示されている場合にも、送信されます。
408	クライアントが要求を開始したが、サーバに設定されているキープアライブタイムアウト内でそれが完了しない場合に、この要求が送信されて接続が閉じられます。 この要求は、開いている別の接続で再度行なうことができます。
411	クライアントが、可変長のチャンクされたエンコーディングで POST 要求を送信しました。 しかし、サーバ上のリソースやアプリケーションは、固定長の「content-length (内容長)」ヘッダーの存在を要求しています。 このコードは、内容長とともにその要求を再度送信するよう、クライアントに指示します。
413	アプリケーション (特定の NSAPI プラグインなど) によっては、大量のデータを処理できないものもあります。その場合、このコードが返されます。
414	URI の長さが、Web サーバがサービスできる最大長より長くなっています。
416	ファイル容量の範囲を越えるデータが要求されました。
500	サーバエラー。 サーバに関連するエラーが発生しました。 サーバ管理者がサーバのエラーログを確認して、何が起こったかを確認する必要があります。
503	「サービス品質」のメカニズムが有効になっており、帯域幅または接続の限界に達した場合に、送信されます。 その後、サーバは該当のコードを使って要求に対処します。 「サービス品質」の節を参照してください。

応答ヘッダー

応答ヘッダーには、サーバと応答データに関する情報が指定されています。 一般的な応答ヘッダーを、表 E-3に示します。

.

表 E-3 一般的な応答ヘッダー

応答ヘッダー	説明
Server	Web サーバの名前とバージョン。
Date	現在の日付 (グリニッジ標準時)。
Last-modified	ドキュメントが最後に更新された日付。
Expires	ドキュメントの有効期限切れの日付。
Content-length	次に続くデータの長さ (バイト)。
Content-type	次に続くデータの MIME タイプ。
WWW-authenticate	認証中に使われ、ブラウザソフトウェアに認証のために何が必要か (ユーザ名およびパスワードなど) を伝える情報が含まれています。

応答データ

サーバは最後のヘッダーの後に空白行を送信します。 その後、イメージや HTML ページなどの応答データを送信します。

バッファ化されたストリーム

---

バッファ化されたストリームは、特に動的なコンテンツを生成する場合に、ネットワーク入出力 (たとえば、HTTP 要求と応答の交換など) の効率を高めます。 バッファ化されたストリームは、透過 NSPR I/O 層として実装されます。これは、既存の NSAPI モジュールでも変更なしでこれらを使用できることを意味します。

バッファ化されたストリーム層は、iPlanet Web Server に次のような機能を追加します。

• キープアライブのサポートの拡張 : 応答がバッファサイズより小さいとき、バッファリング層が content-length ヘッダーを生成し、クライアントが応答の終わりを検出して、その接続を以降の要求のために再使用できるようにします。

• 応答の長さの決定 : バッファリング層は、応答の長さを決定できない場合、content-length ヘッダーではなく HTTP 1.1 チャンクされたエンコーディングを使って、概要情報を転送します。 クライアントが HTTP 1.0 しか理解しない場合、サーバは、応答の終わりを示すために接続を閉じる必要があります。

• ヘッダーの書き込みを遅らせる : サーブレットがそれ自体のヘッダー (たとえば、セッション管理ヘッダー set-cookie など) を生成する機会を与えるために、応答ヘッダーの書き込みをできる限り遅らせます。

• チャンクされたエンコーディングでの要求エンティティ本体を理解する機能 : 一般のクライアントは POST 要求データの送信にチャンクされたエンコーディングを使用しませんが、HTTP 1.1 に準拠するには、この機能が必須となります。

バッファ化されたストリームが提供する改良された接続処理と応答長ヘッダーの生成は、応答長ヘッダーの不在がカテゴリ 1 障害とみなされる、HTTP 1.1 プロトコル準拠の問題にも対応します。 Enterprise Server の以前のバージョンでは、長さヘッダーの送信は動的コンテンツ生成プログラムがその責任を担っていました。 CGI スクリプトが content-length ヘッダーを生成しない場合は、応答の終わりを示すために、サーバがキープアライブメカニズムを中断して接続を閉じなければなりませんでした。 しかし、CGI スクリプトやサーブレットの応答長を追跡し続けるのは非常に不便なこともあり、アプリケーションプラットフォームのプロバイダとしては、このような低いレベルのプロトコルの問題はWeb サーバが処理することを期待しています。

出力バッファリングは、net_write (第 5 章「NSAPI 関数のリファレンス」を参照) のようなデータを送信する関数に組み込まれました。 次のような、ストリームバッファリングに影響する Service SAF パラメータを指定することができます。詳細は 第 3 章「事前定義済みの SAF および要求処理プロセス」に記載されています。

• UseOutputStreamSize

• flushTimer

• ChunkedRequestBufferSize

• ChunkedRequestTimeout

UseOutputStreamSize、ChunkedRequestBufferSize、および ChunkedRequestTimeout パラメータには、対応する magnus.conf 指令も存在します。チャンクされたエンコーディング を参照してください。 obj.conf パラメータは、magnus.conf 指令を上書きします。

---

注	UseOutputStreamSize パラメータを obj.conf ファイル内で 0 に設定して、出力ストリームバッファリングを使用不可にすることができます。 magnus.conf ファイルの場合は、UseOutputStreamSize を 0 に設定しても効果はありません。

---

関数 net_read または netbuf_grab のいずれかを使用する SAF を呼び出すときにデフォルトの動作を上書きするために、obj.conf 内のパラメータの値を指定できます。たとえば、次のようにします。

Service fn="my-service-saf" type=perf UseOutputStreamSize=8192