■ レスポンス・開始行

さて、ネット君。前回リクエストの開始行は説明したな。

え〜っと。メソッド ＋ リクエストURI ＋ HTTPバージョン でしたよね。

うむ。つまり、以下のような行になる。

間にスペースが必要で…。

最後にCRLF、だな。
今回は、レスポンスの場合の開始行を説明しよう。

この順番で、3つの要素からなる。

最初のHTTPバージョンは、リクエストのHTTPバージョンと同じですか？

うむ。サーバが使うことのできるHTTPのバージョンだな。
次がステータスコードと応答フレーズ。これはまとめて説明したほうがいいだろう。

3桁の数字と、その説明？

そうだ。どっかで聞き覚えがあるかもしれんな。

…。

予想された反応をありがとう。
相変わらず君は期待を裏切らないな。

えへへ。

褒めてねぇ。

はぅっ。

ともかく、これだ。見覚えは？

まいくろそふとえふてーぴーさーびす。
USER で 331 Password required for …。FTP？

そうだ。FTPもレスポンスとして3桁の数字とその説明を送っていたな。
FTPの場合は「レスポンスコード」と言ったが。

あ〜、そういえばそんなのもありました。

それと同様に、HTTPでもサーバはレスポンスとして状態を示す3桁の数字を返す。
これがステータスコード。

じゃあ、もちろんFTPと同じように数字に意味があるんですね？

それはそうだ。無意味な数字を送ってもしょうがないだろう。
FTP同様、1桁目でまず意味がある。こうだ。

は〜。100番台、200番台…って意味が違うんですね。

うむ。この違いをクラスという。上の表のクラス名がそれだ。
例えば、100番台のステータスコードは「Informational（情報）」クラスってことだな。

クラス。なるほど。

■ ステータスコード

さて、HTTP/1.1では以下のステータスコードがある。

ひーのーふーの…、39種類ですか。ずいぶん多いですね。

うむ。これを全部説明してもいいが、覚え切れないだろう。

確実に。それだけは断言できます。

いばるな。

はぅっ。

なので、よく使われるものを説明しよう。

これは「OK」だから、リクエストが正常であったということだ。
リクエストがメソッド「GET」だったなら、リクエストURIのファイルを送ることになる。

他のメソッドだったなら？

「HEAD」ならリクエストURIのファイルを送った場合のレスポンスヘッダだけを返す。
それ以外の場合はまた説明しよう。

リクエストURIのファイルは、別のURIに割り当てられているので、そっちをリクエストしてください、というレスポンスだ。

んん？ どういう意味です？

これは、「http://www5e.biglobe.ne.jp/~aji/3min」のように最後がファイル名でなく、さらに「/」がない場合の返答だ。

そういう場合は、3minってファイルを探して、ない場合は「3min/」とみなすんでしたっけ。

そうだ。なのでクライアントに対し、「それは『~aji/3min/』ではないんですか？ そっちを要求してください」と返すのだよ。

は〜。2度もリクエストを送ることになるんですか。
結構面倒くさいですね。

うむ。なので、URIを書くときは最後の「/」をちゃんとつけなければ駄目なのだよ。
あぁ、「http://www5e.biglobe.ne.jp」のように、ドメイン名のすぐ後ろの「/」は省略してもよい。これは自動的に「/」があるものと認識する。

何故ですか？

「http://www5e.biglobe.ne.jp/~aji/3min」は、3minというファイルがある可能性があるからだな。「http://www5e.biglobe.ne.jp」はドメイン名しかないから、ファイルではないということがわかるからだ。

これは、HTTPメッセージの書式が間違っているというエラー。

こっちは、認証失敗というエラー。

認証？

特定のユーザしか見れないようにしてあるページなど、ユーザ名とパスワードの入力が必要な場合だな。

InternetExplorerでは、左のような画面がでてきてパスワードを入力する必要がある。
右は、認証に失敗した時の、MicrosoftIISでの401エラーメッセージ画面だ。

403は、リクエストを正しく受け取ったが、それをサーバが実行したくないというエラーだ。

実行したくないって、なんか我侭だ。

そういうわけではないのだが。
例えば、CGIなどを違うサーバから呼び出すことを禁止していたりする場合はこのエラーになる。

リクエストURIのファイルが存在しないエラーだな。
一番見かけるエラーかもしれん。

あ〜、なんかよく見るかも。

サーバはリクエストを実行しようとしたが、できなかった、というエラーだ。サーバ側の問題で発生する。
一番多いのは、CGIのプログラムが間違っている時だ。

へ〜。プログラムが間違っている。

500のエラーは必ずプログラムミス、というわけではない。
一番多いのが、それだと言う話だ。

なるほど。

自作CGIやら、サーブレットやらで、このエラーが多発して、もう泣きながらプログラムコードを見直したり、画面を殴りつけたり、まぁ人生を垣間見せるエラーだな。

罪作りなエラーですねぇ。

■ 実際の開始行

さて、リクエスト、レスポンスの開始行を説明したわけだが。
HTTP/1.0ならば、この開始行だけでもクライアント・サーバ間のやりとりが行える。

HTTP/1.1では駄目なんですか？

HTTP/1.1では開始行のあとに続くヘッダが必要なのだ。

ふむ、では次はそのヘッダの話ですね。

それもいいが、それは次回にして、せっかく説明したこの開始行をつかってやりとりしてみよう。

お、それはなんかすごそうですね。
ということは、まずブラウザを使うんですね。

ブラウザを使ったら、こちらは何もできないではないか。
telnetを使うのだ。前も話したが、telnetこそは基礎だ。

もしかして、telnetで開始行を打ち込んでいくんですか？

さっしがいいな、その通り。 ではいくぞ。

まずtelnetを起動して。

openでWebサーバのURIを入力するのだが、必ずURIの後ろにスペースを入れて80と入力すること。
そうしないと、telnet接続を行ってしまうからな。

ということは、スペースのあとに80っていれると、Webサーバへ接続しにいくってことですか？

そうだ。スペースの後ろにポート番号を入れるわけだな。
80はHTTPの標準ポート番号だ。

あらら？ まっくらですよ？
それにキーを押してもなにもでてこない。

まっくらなのは、Webサーバに接続しただけだからだ。telnetサーバと違ってWebサーバは接続したからといってなにか反応してくれるわけではない。反応してほしければ、リクエストを送らなければ。

でも、キーを押しても駄目ですよ。

それはローカルエコーがオフになっているからだ。
ローカルエコーとはなんだった？

え〜っと。自分自身で表示するエコーと、第55回で。

そうだ。Webサーバはtelnetでの接続を前提としていないのでリモートエコーを返さない。
さて、コマンドプロンプトでは面倒って人は、前に出てきた「TeraTermPro」というtelnetクライアントを使ってもいいぞ。 ▼ link

コピーアンドペーストが簡単ですからね。

うむ。
では、リクエストの開始行を入力しよう。

ポイントはGETとHTTPは大文字だからな。小文字だとエラーになるから注意が必要だ。
メソッド、リクエストURI、HTTPバージョンの間にはスペースも忘れるな。

大文字…、スペース…っと。

さて、これを入力したらエンターだな。

エンター…。
あれ？ エンターを押したけど何も起きませんよ？

それはそうだ。開始行のあとにエンター、つまりCRLFは必ず必要だったろう？

上であげた例だが、開始行のあとにはCRLF。
つまり、開始行入力後にエンターを一回押しただけではこのCRLFを入力したことになるのだよ。

ということはつまり、リクエスト終わりをしめすエンター（CRLF）がもう一度いるってことですね。

そういうことだな。

へへぇ。では、エンター。

おおっ。

赤い枠内が、レスポンス開始行。ちゃんと「200 OK」になっているだろう？
さらに、青い枠内がメッセージヘッダ。緑の枠内はメッセージ本体。この場合はHTMLファイルだな。

お〜、すごいすごい。
ちゃんと送られてきてる。

当たり前だ。
では、「200 OK」ばかりではつまらないので、今度はこういうリクエストを送ろう。

リクエストURIの最後がファイル名じゃないのに「/」がない。
「301 Moved Permanently」でしたっけ。

うむ。ちゃんとレスポンス開始行に「301 Moved Permanently」が。
メッセージヘッダには正しいURI「/~aji/3min/」があるだろう？

お〜。すごい。なんか感動。

このように、HTTPはリクエスト・レスポンスの開始行を使ってやりとりをすることがわかったと思う。

えぇ、存分に。

うむ。
では、今回はこれぐらいにしておこう。

はい。

次回は開始行の後ろに続くメッセージヘッダの話をしよう。

いぇっさ〜。
３分間ネットワーキングでした〜♪