社内研修「HTTPから学ぶTCP/IP基礎」(8)

前回よりHTTPレスポンスの内容について解説しています。
今回はHTTPレスポンスのメッセージヘッダについて説明をします。
メッセージヘッダの形式は、リクエストと同じで、
ヘッダフィールド：フィールド値となっています。

では、よく使われるヘッダフィールドについて説明をします。
リクエストのメッセージヘッダの回で出てきたフィールドヘッダについては、該当回へのリンクを貼っていますので、そちらもご参照ください。

Location

Location:http://www.ois-yokohama.co.jp/
第7回で少し出てきましたが、レスポンスのステータスが300番台(リダイレクト)の場合に、リダイレクト先を指定します。ただし、304 Not Modifiedの場合はキャッシュを使用するのでLocationヘッダフィールドはありません。
 

Server

Server：nginx
Webサーバの種類を示す値が入っています。
上記の例では Webサーバがnginxであることを示しています。WebサーバによってはバージョンやOSの情報も入っていることもあります。

WWW-Authenticate

WWW-Authenticate：Basic realm=’Enter username and password.’
第5回のAuthorizationヘッダフィールドのところで説明しましたが、HTTPにはリソースに対して認証をかけることができます。認証が必要なリソースに対して、Authorizationが設定されていない、または、不正な場合は、レスポンスステータス401 Unauthorizedを返却します。その際、WWW-Authenticateヘッダフィールドを付け、認証方式やパラメータをWebブラウザに通知します。
上記は認証方式がBasic認証であることを表しています。realmに設定された値は入力ダイアログのメッセージに使用されています。

Content-Encoding

Content-Encoding:gzip
第3回のAccept-Encodingヘッダフィールドで説明をしましたが、通信量を減らす仕組みとして、レスポンスの本体部を圧縮することができます。Accept-Encodingヘッダに設定された圧縮方式の中で、対応可能な方式があれば採用し、Content-Encodingに設定します。
上記はレスポンス本体部がgzipで圧縮されていることを表しています。
Yahoo、livedoorなど、大手ポータルサイトはgzipに対応しているところが多いようです。

Content-Type

Content-Type:text/html
第6回のリクエスト本体の説明の中で、Content-TypeにはMIMEと呼ばれるコンテンツの種類を設定する、と説明しました。これは、レスポンス本体部でも同じです。
HTML、Javascript、CSS、画像ファイル、バイナリファイルのMIMEは以下の通りです。

MIME	説明
text/html	HTMLファイル
text/javascript	Javascriptファイル
text/css	CSSファイル
image/png	PNGファイル
application/octet-stream	バイナリファイル

MIMEによって、Webブラウザでリクエストを受け取ったときの挙動が変わります。たとえば、PNGファイルの場合、image/pngだと画面に画像が表示されますが、application/octet-streamするとダウンロードのダイアログが出てきて、PNGファイルがダウンロードされます。
MIMEの設定ですが、通常はWebサーバの設定ファイルで拡張子とMIMEが紐付けされており、それに基づいて自動で設定されるので、アプリケーションで操作するのは上記の様にWebブラウザの挙動を変えたい場合くらいかと思います。

Content-Length

Content-Length:123456
レスポンス本体のサイズをバイトで設定します。

Transfer-Encoding

レスポンス本体のサイズが分からない場合に、Content-Lengthの代わりに使用します。Content-LengthとTransfer-Encodingの違いは以下の通りです。
Content-Lengthの場合
Content-Lengthを設定する場合、レスポンス本体のサイズがわかるまでレスポンスの送信を開始することができません。動的なペー ジであれば、レスポンス本体をバッファリングして出力し終えたあとでContent-Lengthを設定する必要があります。バッファ領域が必要になりま すし、何より出力し終えてからでないと送信を開始できないため、非常に非効率です。

Transfer-Encodingの場合
Transfer-Encodingのフィールド値はchunkedのみです。Transfer-Encoding:chunkedが設定されている場 合、Content-Lengthは設定されておらず、代わりにHTTPレスポンス本体に塊(chunk)ごとのサイズと本体が設定されます。

Cache-Control、Expires、Last-Modified、Etag

キャッシュに関するヘッダフィールドです。第4回を参照ください。

HTTPヘッダまとめ

これまで、リクエストとレスポンスの両方のヘッダについて説明をしましたが、ヘッダフィールドの分類としては以下の4つがあります。

一般ヘッダ

Cache-Control、Dateなど、リクエスト、レスポンスの両方に使用できるヘッダフィールドです。

要求ヘッダ

Accept-Encoding、Accept-Language、If-Modified-Sinceなど、リクエストにしか使用できないヘッダフィールドです。

応答ヘッダ

Location、Etag、Serverなど、レスポンスにしか使用できないヘッダフィールドです。

エンティティヘッダ

Content-Type、Content-Lengthなど、本体部の情報を示すためのヘッダフィールドです。

RFCで規定されているヘッダ以外にも、Webサーバ、Webブラウザが独自に実装しているヘッダもありますので、興味があれば調べてみてください。

第8回は以上です。

さて、次はHTTPレスポンス本体の話になるところですが、これまでの説明の中でレスポンス本体についての内容も出てきており、他に説明する内容はありませんので、割愛させていただきます。
HTTPリクエストおよびレスポンスの説明については今回で終了し、次回はプロキシを使用する場合のHTTP通信について説明をします。