銀色うつ時間

思い出すたび何か胸につっかえてるだけ

HTTPってなんなの 2/2

HTTP

※第２回目

前半はこちら

http://d.hatena.ne.jp/arerreee/20120821/1345568635

さて、前回はHTTPプロトコルの概要およびHTTPリクエストが果たす機能について説明した。今回はHTTPにおいてリクエストの受け手であり、返してであるHTTPレスポンスの役割についてまとめていく。

HTTPレスポンスの構成

通信の開始は常にクライアント側であり、クライアントが投げるリクエストに対してサーバーは何かしらのリアクションを返す、というHTTPの基本原則は前回のエントリで触れた。HTTPレスポンスとは、受け取ったリクエストに応じてサーバー側からクライアント側に送られる情報である。

HTTPレスポンスは、以下の情報群によって構成されている。

  • レスポンスステータス行
  • メッセージヘッダ
  • データ本体（メッセージボディ）

状態を表すコードが第１行目に登場し、その後詳細な情報を表すヘッダ部が続き、最後にメッセージボディが送られる。この構造はクライアント側から送られるHTTPリクエストと殆ど同一のものであることがわかる。実際に前回HTTPリクエストを確認した2chにアクセスしたときに送られてきたレスポンスを調べてみる。

HTTP/1.1 200 OK
Date: Thu, 30 Aug 2012 13:59:10 GMT
Server: Apache/2.2.15
Last-Modified: Wed, 02 Jun 2004 15:33:37 GMT
Etag: "e8280b-1b63-3dbe269f6b640"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 2174
Connection: close
Content-Type: text/html

これらの情報が私たちのブラウザに送られた後に、メッセージボディ（つまりは2chのhtmlデータや画像）が送られてくるというわけだ。そのデータをブラウザが構築することでこのページが表示されている、というわけ。

http://www2.2ch.net/

レスポンスステータス行

HTTPレスポンスにおいてまず何より大事なのが１行目のステータス行だ。

HTTP/1.1 200 OK

最初の"HTTP/1.1"の部分はWebサーバーがサポートするHTTPのバージョンを表している。次に続く"200"こそがなじみ深いHTTPステータスコードだ。これは要するにアクセスするクライアント側への結果発表みたいなもので、ブラウザからのリクエストをサーバーがどう処理したかを番号で表している。考えてみれば当然で、ホスト側に伝える大量の情報群の中でも、最初に伝えるべきなのは結果なのだ。その辺の書類と同じである。最後の「OK」の部分は、ステータス・コードの補足説明。ここでは無事に要求通りのものをサーバーが持ってきたことを示している。

さて、404や403など、誰でも知っているようなステータスコードもあるだろうが、他にはどのようなものがあるだろうか。先日素晴らしいコンテンツがインターネットで話題になっていたのでそちらを紹介し、ここでは主要なものに留めることにしておく。ぜひ目を通しておきたい。

先輩と覚える HTTP ステータスコード ― Gist - Gist - GitHub

https://gist.github.com/3401612

  • 1xx Informational リクエストはサーバーに届けられ、処理は継続する。
  • 2xx Success リクエストはサーバーに受理される。200:要望通りのモノをもってきた。成功。おっけー。
  • 3xx Redirection リクエストを完了させるために、さらなる処理が必要。
    • 301:恒久的な移動。Locationヘッダに移動先は記述される。「このホームページは引越ししました。10秒後に・・・」
  • 4xx Client Error クライアント側のリクエストに誤りがあった。お前何言ってるかわかんねーよ。
    • 403:Forbidden。リソースにアクセスすることを禁止されている。サーバー側から排他的な処理がなされている場合が多い。アク禁。
    • 404:Not Fouund。そんなものなかった。
  • 5xx Server Error サーバー側がリクエストの処理に失敗した。
    • 500:Internal Server Error。サーバー内部にエラーがあった。プログラムの文法ミスなどで処理が止まるなど。
    • 502:Bad Gateway。ゲートウェイ・プロキシサーバーが不正なリクエストを受け取り、これを拒否した。
レスポンスヘッダ部分

リクエストのヘッダフィールドと同じく、レスポンスヘッダフィールドも

フィールド名： 内容

という形式で表される。今回サーバーから受け取った情報を順に見ていく。

Date: Thu, 30 Aug 2012 13:59:10 GMT //メッセージの作成日時を示す
Server: Apache/2.2.15 //サーバのベンダー名、バージョン番号を示す
Last-Modified: Wed, 02 Jun 2004 15:33:37 GMT //オブジェクトが最後に変更された日時を示す
Etag: "e8280b-1b63-3dbe269f6b640" //オブジェクトのエンティティタグ値を示す。ネットワークの帯域を節約するための キャッシュの管理で用いられる。
Accept-Ranges: bytes //オブジェクトの一部に対するリクエストをサーバが受け入れ可能か示す
Vary: Accept-Encoding //サーバがレスポンス内容を決定する際にリクエストURI以外に用いたヘッダのリストを示す
Content-Encoding: gzip //オブジェクトのエンコーディングを示す
Content-Length: 2174 // 	オブジェクトのサイズをバイト単位で示す
Connection: close //中間システムが転送すべきでないヘッダのリストを示す
Content-Type: text/html //オブジェクトのタイプを示す

その他のヘッダで重要なものとしては、set-CookieやLocationが挙げられる。

クッキーは、まずサーバがSet-Cookieというヘッダを発行する所から始まる。これをクライアントは受け取り、次回以降のアクセスでsetされたCookieをリクエストヘッダに付加してサーバーに送ることでサーバーは一意のクライアントを判別することができ、ショッピングカートや視聴履歴といったシステムが可能となる。サーバがクライアントにクッキーを送る時のレスポンスヘッダは以下のような形式となる。

Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME; secure

set-Cookieヘッダを利用してsessionIDをクライアントに送ることでユーザーを同定しているのだから、これさえ入手すれば第三者ユーザーになりすますことも当然可能である。好きな女の子のCookie情報をこっそり引っ張ってこれれば、などと考えてしまう人が時折登場するのも性である。ブラウザが持つCookieとはそれほどに尊いものなのだ。

  • Location

これはステータスコード3xx系でよく用いられる。Locationヘッダフィールドは、リクエストの完了や新しいリソースの識別をするため用いられる。受信者をRequest-URI以外の場所にリダイレクトするってこと。3xxレスポンスの場合、Locationはリソースへ自動でリダイレクションさせるためにサーバが望むURIを示すべき。単一の絶対 URI から成る。 

Location: http://www.w3.org/pub/WWW/People.html

まとめ

HTTPレスポンスはレスポンス行、ヘッダフィールド、メッセージボディの３つに大別され、レスポンス行では応答のサマリーとして状態を示すステータスコードが記載され、以降のヘッダフィールドにはクライアント側に返すのに必要な形式やサイズといったメタ情報が記されていることが分かった。それらの情報の後にクライアント側が要求するオブジェクト、すなわちhtmlやcssといったコードや画像や音声といったバイナリデータが本体として送信されている。前エントリで学んだリクエストヘッダを受けたサーバーがこのような処理を行うことで、HTTP通信が行われる。主要なステータスコードやヘッダフィールドはちゃんと覚えておきましょう。全2回に分けるほどHTTPで学ぶべき領域は膨大であった。「未だHTTPの5%も理解できていないのでは」とも思うが、今回は一応これで区切りとしておく。

なにか間違いがあったらご指摘ください！