■ メソッド

さてさて。ネット君、メソッドについては説明したな。

え〜っと、リクエストヘッダにある動作の指定、でしたっけ？

うむうむ。ちなみにリクエストメッセージの中身はこの形、だったな。

この開始行にあるものだな。でもって、種類は以下の種類だ。

でしたでした。

今回は、メソッドについてもうちょっと詳しく説明しよう。
だがしかし。

だがしかし？

ブラウザや、Webサーバアプリケーションによって動作に微妙な違いがあったりなかったりするので、そこらへんだけは要注意だ。

あったりなかったりって、どっちなんです？

あったりなかったり、だ。

いえ、だから、どっちなんです？

君もしつこいな。
どうしてそのしつこさが物事を覚えるという点に関してまったくいかされないのが不思議だよ。

はぅっ。

■ GET

まずGET。リソース回収するためのメソッドだ。
つまり、リクエストURIに書かれたリソースを要求することだな。

一番使われる「ページを見る」ためのメソッドですよね。

そういうことだな。GETについてはあまりに標準なのであまり話すこともないが、まぁ2つほど話しておこう。
1つ目は条件つきGETだ。

条件つき？ どんな条件がつくんです？

うむ、これには前回説明したメッセージヘッダの中の「If-Modified-Since」が使用される。

いふもでぃふぁいどしんす？
Modifiedってどんな意味でしたっけ？

「修正済み」って意味だな。
「If-Modified-Since」の値は日付だ。前回使ったEtherealを使って、どのような値が送られているか見てみると。 ▼ link

2004年10月6日、14：27：37という値がサーバに送られている。
まぁ、GMTだから、実際は2004年10月6日23時ってことだな。

ははぁ。で、これはなんの時間なんですか？

ユーザエージェントはキャッシュとして以前取得したページを持っている。
そのキャッシュされたページの更新日時がIf-Modified-Sinceってことだ。

はぁ。

でもって、このIf-Modified-Sinceがついた条件つきGETではこう問い合わせているわけだ。
「もしIf-Modified-Sinceより後に更新されていたら、GETします」と。

ははぁ。だからもし(if)、この日時から(since)、修正された(Modified)なら、ってわけですか？

そうだ。さっきのEtherealの要求に対しての返答を見てみよう。

もし、If-Modified-Sinceの値以降に更新されていたなかったら、304 Not Modifiedを返す。この時、ページを送らないわけだな。

ページを送らない？

「あなたの持っているキャッシュと変わらないですよ」ってことだな。
う〜む、動きがあったほうがわかりやすいか？

は〜。同じページをわざわざ送らないってことですか。

そういうことだな。それにより、転送量を減らす役割があるわけだ。

なるほど。
ところで、キャッシュってどこにされるんです？

それはブラウザによって異なる。
さて、GETに関してもう1つ。CGIなどの動的ページの場合だ。

CGIっていうと、アレでしたっけ。掲示板とかに使ってるやつでしたっけ？

うむ。「Roads to Node」でもCGIを使った掲示板を持っているな。
CGIをGETで要求する場合、要求URIはこのような形だ。

ここでの問題は、このURIはCGIソースであって、HTMLファイルではない、ということだ。

？

つまり、上の例の「ibbs.cgi」というファイルは、Perlという言語で書かれたプログラムファイルなのだよ。
中身はこんな感じだ。

Roads to Nodeでは「CJ-Club」の「I-Board（の旧ver）」と呼ばれるフリーのCGIを使わせてもらってる。 ▼ link

なんです、これ？
全然HTMLじゃないですよ？

だろう？ CGIのような動的ページについては後述するとして。
本来のGETの意味からすれば、このPerlで書かれたソースファイルを取得しなければおかしいわけだ。

そうなりますかね。

だが、実際GETが取得してくるのは、CGIによって生成されたページ、となるわけだ。こういう動作もGETは行う、ということだな。

なるほど。

■ HEAD

次はHEADを説明しよう。
HEADはレスポンスヘッダのみを要求するメソッドだ。

見てわかるようにGETの場合と同じレスポンスヘッダを返す。
違いはレスポンスボディ、つまりデータがないだけだ。

レスポンスヘッダだけ取得して、なにかいいことあるんですか？

確かに通常のブラウザでは、HEADメソッドを使うことはない。

ないんですか。
ブラウザが使わないってことは、なんか他に使い道があるんですか？

所謂、巡回エージェントなどがよく使うな。
設定されたURIに対し、HEADリクエストを行い、ページの更新状況などを確認するソフトウェアだ。

ははぁ、そんな便利なソフトがあるんですか。

私が知っているのだと、WWWCがあるな。 ▼ link

ははぁ。なんでその巡回エージェントとやらはGETを使わないんですか？
GETでもさっきの条件つきGETを使えば更新状況がわかるじゃないですか？

確かにそうだが。GETだと更新されている場合、ページを送り返してくるだろう？
更新されているかどうか判断するだけなら、HEADだけでも十分だ。

確かにそうかも。

まぁ、せっかくだから、HEADメソッドを使った場合も見てもらおう。
自宅サーバのIIS5.0に対し、telnetクライアントを使って、HEADメソッドを実行した場合だ。

と、このように普通に「200 OK」が返ってきているが、データとしてページが送られてきていないわけだ。

ははぁ。

■ POST

次はPOST。
これはなんと説明したっけ？

「要求メッセージのメッセージ本体にデータを入れて送る時に使う」と。

そうだな。掲示板などクライアント側からのデータに応じて変化する、動的ページなどではこのメソッドが使用される。

上の例は、掲示板などの場合だ。掲示板に書き込んだものがデータとして渡されるわけだな。

えぇ〜っと、つまり。POSTで要求を出したページに、その、掲示板に書き込んだものをデータとしてくっつけて送って。
で、その結果をページとして受け取るってことですか？

うむうむ。なかなかいい理解力だぞ。
実際の例を見てもらおうか。Roads to Nodeの掲示板に書き込んだ時の状態をEtherealで見た場合のものだ。

実際、長いのでカットしたが。この「Line-based text data」というところが書き込んだデータだ。
ヘッダ終了の改行の後に、続いているだろう？

「no=0」とか「mode=wri」とかの部分ですよね？
どういう意味なんです？

それはデータを送る時のHTMLファイルの記述によるもので、必ずこうなるというわけではない。
わかってほしいのは、リクエストメッセージなのに、ヘッダだけでなくデータを送っているという点だな。

ははぁ、確かに。
ヘッダ終了の改行があっても、その後ろにまだデータがありますものね。

うむ。そして、送られてきたデータによってCGIを使って作成されたページをサーバは送るわけだな。
この場合は、200 OKになるわけだ。

なるほど。

CGIのような動的ページの場合、POSTを使う場合と、GETを使う場合がある。
どこで区別するかというと、CGIを呼び出すページのHTMLソースで決まる。ココだ。

ココを「method="POST"」とするか、「method="GET"」とするかで、使用するメソッドが異なる。

へ？ GETを使う場合があるんですか？
なんか今までの説明を聞くと、CGIのようなデータが必要な場合はPOSTを使うってことっぽいですけど？

確かに「データを送る」時はPOSTだ。だが、これはCGIの仕組みによっていろいろあるのだよ。
詳しくはCGIを使うときに説明しよう。

ははぁ。
……なんか最近、「後述する」とか「また後で説明しよう」が多いですね。

む。
むむぅ。

あ、博士が珍しく困ってる。へへへ。

ネット君？

はい？

君はいらん事によく気がつくな。

えへへ。

褒めてねぇ。

はうっ。

■ PUTとDELETE

さて、GET、HEAD、POSTはHTTP1.0までに規定されたものだが。
HTTP1.1で新しく入ったメソッドもいくつか紹介しよう。PUTとDELETEだ。

PUTは「置く」？ DELETEは「消す」？

その通り。つまりHTTPを利用したサーバ上のファイルの作成・更新・削除に使用するメソッド、ということだな。

え？ え？ HTTPって「見る」ためにあるんじゃないんですか？
サーバ上でファイルを作成したり、更新したりしたら、それはFTPじゃないですか？

おいおい。前に話したろう？ WebDAVというものがあると。
HTTP1.1ならば、FTPに近いこともできると。

そういえば、HTTPの歴史の話の時にそんな話をしてたような…。

まったく。
ともかく、ファイルの作成、更新を行うためのメソッドがPUTとGETだ。

リクエストヘッダのURIに、作成するファイルの名前。
データに、そのファイルの中身を入れて送るわけだな。

で、レスポンスが201 Created？
Createだから、作成したって返事ですか？

そうだ。すでにファイルが存在して、中身の入れ替えの場合は200 OKになる。
ではちょっとやってみよう。

ちょっと不必要な部分を省略して見せているが。
ちなみにtelnetクライアントを使って実行する場合には、Content-lengthヘッダが必要だ。

は〜。

今のがファイルの新規作成。次は更新を見せてみよう。

あ、ほんとに200 OKになってる。

うむ。更新だからCreateしたわけではないから、200 OKだ。
最後はDELETEをやってみよう。

あれ、またも200 OKだ。

そうだ。つまり200 OKというのは、メソッドに対して正常に実行できた場合のレスポンスコードなわけだ。
このDELETEの場合は、「正常に削除できました」というレスポンスになるわけだ。

なるほど。

あぁ、そうそう。このPUTとDELETEの例は、IIS5.0での例だからな。
他のWebサーバアプリケーションでは試したことがないので。あしからず。

博士、Windows好きですねぇ。

好きと言うわけではないが、特に用意したりするものが必要ないからな。例にはぴったりだろう。

そういうもんですか？

そういうものだ。

ははぁ。

では、このぐらいにしておこうか。

あれ？ OPTIONSやTRACEやCONNECTは？

まぁ、あまり使うメソッドではないからな。
どちらかといえば、Webサーバアプリケーションやプロキシに対する診断用のメソッドだ。

そうなんですか。

うむ。
では、また次回。

了解です。 ３分間ネットワーキングでした〜♪