CHROMA

世の中の "当たり前" を確認する

HTTPヘッダー

先週書いた「HTTPメッセージ」という記事でも少し触れましたが、今回は各ヘッダーフィールドの役割についてもう少し書いてみようと思います。

まず、ヘッダーフィールドとは、クライアントとサーバーの通信のなかで指示を出したり、指示に対する処理結果を示す場所のことです。
ヘッダーフィールドは HTTP メッセージヘッダーに含まれています。

f:id:thleap:20140812192655p:plain

そして、このヘッダーフィールドの各要素はそれぞれの用途から次の4種類に分けられます。

  • 一般ヘッダーフィールド
  • リクエストヘッダーフィールド(リクエストメッセージ)
  • レスポンスヘッダーフィールド(レスポンスメッセージ)
  • エンティティヘッダーフィールド

リクエストヘッダーフィールドはリクエストメッセージに、レスポンスヘッダーフィールドはレスポンスメッセージにのみ含まれます。あとの 2つのヘッダーフィールドについては、リクエストとレスポンス、どちらにも含まれます。

これらに分類されるヘッダーフィールドは RFC2616 で定義されたものです。しかし、Cookie や Set-Cookie のように RFC 以外で定義され、現在でも広く使われている非標準ヘッダーフィールドもいくつか存在します。

一般ヘッダーフィールド

ここには Cache-Control (中間キャッシュの動作の指示) や Date (メッセージの作成日時を示す)といったヘッダーフィールドが含まれます。

一般ヘッダーフィールドは、リクエストとレスポンス両方のメッセージに含まれるヘッダーフィールドです。

リクエストヘッダーフィールド

ここには Host (リソースのインターネットホストとポート番号を示す) や If-XXXIf-Match のような条件付きリクエスト)といったヘッダーフィールドが含まれます。

リクエストヘッダーフィールドでは、クライアントからサーバーに向けてリクエストを送る際に、クライアントの情報を伝えたり、条件に合ったリソースを返すように指示を出したりします。

レスポンスヘッダーフィールド

ここには ETag (リソースを特定するための情報を示す) や Location (リソースの場所を示す)といったヘッダーフィールドが含まれます。

レスポンスヘッダーフィールドでは、サーバーからクライアントに向けてレスポンスを返す際に、管理しているリソースの情報を伝えたり、リクエスト通りの処理が出来なかった場合にクライアントに対してリクエストの再要求を行ったりします。

エンティティヘッダーフィールド

ここには Allow (リソースがサポートしている HTTP メソッドを示す)や Content-Length (エンティティボディのサイズを示す)といったヘッダーフィールドが含まれます。

エンティティヘッダーフィールドは、コンテンツのタイプやサイズを示すヘッダーフィールドです。

ヘッダーフィールドの詳細について

ヘッダーフィールドの詳細については、HTTPの教科書の第6章や、Wikipedia の「HTTPヘッダフィールド」という項目にまとめられています。
気になる方は一度見てみてください。

量が多く、僕はすべての内容を覚えることが出来ませんでしたが、一度見ておくとそれぞれの役割が少しは分かった気になれて良かったです。