この頁では、HTTPヘッダとは何かについて、またHTTP/1.1仕様書などで定義されているHTTPヘッダのうち代表的なものを解説します。
クライアントとサーバは、HTTPヘッダを使ってデータやソフトウェア自身の情報をやりとりしていきます。 HTTP/0.9では、データの取得のみを目的としていたので、HTTPヘッダというものは存在しませんでした。 しかし、WWWが活用され始め、リソースのサイズや更新時刻といった「取得するリソースに関連する情報」や、あるいはユーザエージェントの種類やそれを参照するリソースのURIなどの「クライアント側の情報」をやりとりしたいと思うようになり、実際のリソースとは別のメタ（外部）情報を扱うものとして、HTTPヘッダが開発されたのです。
では、HTTPヘッダは実際にはどのような値を取るのでしょうか? RFC 2616の section 4.2をご覧下さい。
一般ヘッダ (section 4.5)、リクエストヘッダ (section 5.3)、レスポンスヘッダ (section 6.2)、エンティティヘッダ (section 7.1) 各フィールドを含む HTTP ヘッダフィールドは、RFC 822 の Section 3.1 で与えられているものと同じである共通のフォーマットに従う。 それぞれのヘッダフィールドは、名前、その後にコロン(":")、そしてフィールド値から成る。 フィールド名は、大文字・小文字を区別しない。 フィールド値には、いくつもの
LWSを先行させる事ができるが、SP一つだけが好ましい。 ヘッダフィールドは、一つ以上のSPやHTをそれぞれの行頭につける事で複数行にまたがる事ができる。 アプリケーションが HTTP 構造を生成する時には、"共通形式" を超えたものは受け入れられない実装がいくつか存在するであろう事を考慮し、知られている、あるいは示されている "共通形式"に従うべきである。message-header = field-name ":" [ field-value ] field-name = token field-value = *( field-content | LWS ) field-content = <field-value を構成し、*TEXT あるいは token, separators, quoted-string を連結 したものから成る OCTET>
field-contentは、LWSを前にも後ろにも、すなわちfield-valueの最初の空白以外の文字の前にも、あるいはfield-valueの最後の空白以外の文字の後ろにも、含まない。 そのような前後のLWSは、フィールド値の意味論を変える事無く削除されるであろう。field-contentの間のいかなるLWSもフィールド値に解釈されたり、下流{downstream} に転送される前に単なるSPに置き換えられるであろう。
BNFに従うと、ヘッダ名（field-name）に使用できるのはtokenのみですが、ヘッダの値（field-value）では*TEXTが使用できるため、RFC 2047の規定に従ってエンコードされれば、日本語も使用できます。
但し、ヘッダによっては、定義で取れる値が決まっているものがあります。
（※）日本語を使用できるといっても、使用する文字セットをあらかじめ転送先と合意しておかなければ文字化けの可能性があります。 文字セットにUTF-8を使用する拡張については、パラメータにUTF-8を使用するをご覧ください。
現在提案されている全てのHTTPヘッダはRFC 4229としてまとめられています。 本書では、RFC 2616に定義されているHTTPヘッダ、およびそれ以外のRFCにて定義され、広く利用されている非標準ヘッダのいくつかを解説します。
RFC 2616 では、全部で 47 種類の HTTP ヘッダが定義されています。 以下では、その中のうちの代表的なものを解説します。
Accept リクエストヘッダフィールドは、レスポンスで受け入れ可能なメディアタイプを指定するために使われる。 Accept ヘッダでは、インラインイメージを要求する場合などに、希望するタイプの小セット{small set} を特に限定して指定するために使われる。
Accept = "Accept" ":" #( media-range [ accept-params ] ) media-range = ( "*/*" | ( type "/" "*" ) | ( type "/" subtype ) ) *( ";" parameter ) accept-params = ";" "q" "=" qvalue *( accept-extension ) accept-extension = ";" token [ "=" ( token | quoted-string ) ]アスタリスク "*" という文字は、ある範囲のメディアタイプをグループ化するために使われ、"*/*" ではすべてのメディアタイプを表し、"type/*" はそのメディアタイプに含まれるすべてのサブタイプを表す。
media-rangeは、その範囲に適用できるメディアタイプパラメータを含む事ができる。それぞれの
media-rangeでは、相対的な品質係数を示すため "q" で始まるパラメータを、一つ以上accept-paramsとして付加する事ができる。 もし "q" パラメータがあれば、最初の "q" パラメータがmedia-rangeとaccept-paramsを分けるものとなる。品質係数によって、ユーザやユーザエージェントは 0 から 1 までのqvalue尺度 (section 3.9) を使って、そのメディアタイプの相対的な優先度を示す事ができる。既定値は、q=1 である。
ユーザエージェントが処理できるメディアタイプを記述するためのフィールドです。
たとえば、古いブラウザが PNG の画像を表示する事ができず、JPEG 形式の画像を転送して欲しい場合は、Accept フィールドに image/jpeg を指定して image/png を指定しない様にします。
詳しくは、サーバ駆動型ネゴシエーションをご覧ください。
(※) 上記中、"*/*" では全てのメディアタイプを表し
とありますが、実際は上手く扱えないタイプがあるにも関わらず、これを送信してしまうクライアントがあります。
クライアントが正しく扱えるタイプを判別するための技術については、RFC 2936を参照して下さい。
Accept-Charset リクエストヘッダフィールドは、レスポンスで受け入れ可能な文字セットを示すのに使われる。 このフィールドは、一般的な文字セットや、特殊な目的を持つ文字セットを理解できるクライアントがそれらの文字セットの中で文書を表現する能力を持つサーバに対して、利用できる文字セットを通知する事を可能にする。
Accept-Charset = "Accept-Charset" ":" 1#( ( charset | "*" )[ ";" "q" "=" qvalue ] )文字セット値は、section 3.4 で記されている。 それぞれの文字セットに、ユーザの望む文字セットの優先度を表す関連付けられた品質値を付ける事ができる。 既定値は 1 である。 次の例を見よ。
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8特別な値である "*" が Accept-Charset フィールド中にある場合、その Accept-Charset フィールドにて指定されていないすべての文字セット (ISO-8859-1を含む) に合致する。 もし、"*" が Accept-Charset フィールドで与えられていなければ、明示されていないすべての文字セットの品質値は 0 である。 但し、ISO-8859-1 が明示されていない場合は、その品質値は 1 である。
Accept-Charset ヘッダが無い場合、既定ではどんな文字セットも受け入れ可能である。 Accept-Charset ヘッダがあっても、サーバが Accept-Charset ヘッダによって受け入れ可能なレスポンスを返せない場合、サーバは、クライアントが扱えないレスポンスを返す事もできるが、406 (not acceptable) エラーレスポンスを返すべきである。
クライアントが受け入れ可能な文字セットを示すために使用されます。 詳しくは、サーバ駆動型ネゴシエーションをご覧ください。
言語タグを利用して、ユーザが利用したい自然言語を表すために使用します。 詳しくは、言語タグを含むHTTPの通信シーケンスを参照ください。
サーバが、部分的レスポンスのサポート有無や、リソースのレンジ単位を記述するためのフィールドです。 詳しくは、レンジ単位とはをご覧ください。
Age レスポンスヘッダは、オリジンサーバがレスポンスを生成した (あるいは再検証した) 時点からの送信者の推定経過時間を示す。 キャッシュされたレスポンスは、経過時間{age} がその使用有効期限{freshness lifetime} を過ぎていなければ、新鮮である。 Age 値は、section 13.2.3 で記述されたように計算される。
Age = "Age" ":" age-value age-value = delta-secondsAge 値は、負でない整数値であり、秒数を表す。
もしキャッシュが表現できる以上の正の整数値を持っていたり、その経過時間計算でオーバーフローしたら、2147483648 (2^31) という値の Age ヘッダを送らなければならない。 キャッシュを持っている HTTP/1.1 サーバは、自身のキャッシュからのすべてのレスポンスにおいて、Age ヘッダフィールドを含まなければならない。 キャッシュは、少なくても 31bit の範囲はある計算型を使うべきである。
そのリソースが生成されてからの経過時間を表すためのヘッダです。 このヘッダは、例えば、あるリクエストに対して、キャッシュサーバが Age ヘッダを含むキャッシュされたレスポンスを返す場合に利用できます。 この場合、クライアントは Age ヘッダを調べ、既にそのレスポンスが新鮮でなくなっていたならば、オリジンサーバに最新のレスポンスを求めるためにリクエストをする必要があります。
Allow エンティティヘッダフィールドは、Request-URI によって識別されるリソースがサポートするメソッドの一覧を示す。 このフィールドは、リソースに関する有効なメソッドを受信者に厳密に知らせる事を目的にする。 Allow ヘッダフィールドは、405 (Method Not Allowed) レスポンス中に存在しなければならない。
Allow = "Allow" ":" #Method使用例を見よ。
Allow: GET, HEAD, PUT
その Request-URI にあるリソースが受け付けるメソッドのリストを含むヘッダです。 サーバが受け入れられないメソッドを受けた場合には、405 と共に、適切な Allow ヘッダを返さなければいけません。
HTTP認証において、保護された領域{realm}に入るための認証情報を含めるためのヘッダです。 詳しくは、HTTPアクセス認証のためのHTTPヘッダをご覧下さい。
Cache-Control 一般ヘッダフィールドは、リクエスト/レスポンス連鎖上のすべてのキャッシングメカニズムが従わなければならない指示を記述するために使用される。 キャッシュがリクエストやレスポンスに不利になるように干渉させないような振る舞いを指定する。 これらの指示は、常に既定のキャッシングアルゴリズムを上書きするものである。 キャッシュ指示は、リクエスト中にある指示があっても、それと同じ指示がレスポンスで与えられるという事を暗に意味しない、という意味において単向性である。
HTTP/1.0 キャッシュは、Cache-Control を実装してせず、Pragma: no-cache (section 14.32 参照) しか実装していないかもしれない事に注意せよ。
キャッシュに対して、その振る舞いを決定するための指示子を記述します。 Cache-Control に含まれる指示子は、Expires や Pragma に優先します。
詳しくは、キャッシュ期限モデルをご覧下さい。
Connection 一般ヘッダフィールドは、送信者が特定の接続のために望むオプションを指定する事を可能にするが、介在するプロクシとの接続を超えて伝達してはならない。
Connection ヘッダは、以下の様な文法を持つ。
Connection = "Connection" ":" 1#(connection-token) connection-token= token
Connection ヘッダには、主に二通りの使用法があります。
一つは、Connection ヘッダに close という値をセットする事で、持続的接続を終了する事ができるというものです。
HTTP/1.1 では、送信者がレスポンスを完了した後に接続を切断するという事を合図する "
close" 接続オプションを定義する。次の例を見よ。Connection: closeこの場合、リクエスト・レスポンスのどちらかのヘッダフィールドの場合でも、その接続は現在のリクエスト/レスポンスが完了したら、「持続的」(section 8.1) であるとみなすべきではない。
持続的接続をサポートしていない HTTP/1.1 アプリケーションは、すべてのメッセージに "
close" 接続オプションを含めなければならない。
もう一つは、Connection ヘッダに「同時に使用するヘッダ名」を含める事で、そのヘッダをホップバイホップヘッダにする事ができます。
HTTP/1.1 プロクシは、メッセージが転送される前に Connection ヘッダフィールドを解析し、フィールド内の各
connection-tokenごとに、connection-tokenと同じ名前を持つヘッダフィールドをそのメッセージを削除しなければならない。 接続オプションは、その接続オプションに関するパラメータが無ければ、追加的ヘッダフィールドは送信されないかもしれないので、対応する追加的ヘッダフィールドによってではなく、Connection ヘッダフィールド内のconnection-tokenによって表される。Connection ヘッダ内に列挙されるメッセージヘッダは、Cache-Control のようなエンドトゥエンドヘッダを含めてはならない。
エンドトゥエンドヘッダとホップバイホップヘッダの解説は section 13.5.1 にあります。
キャッシュや非キャッシュプロクシの振る舞いを定義する目的のために、我々は HTTP ヘッダを二つのカテゴリに分ける。
- エンドトゥエンドヘッダ。これはリクエストやレスポンスの最後の受信者に転送されるものである。レスポンス中のエンドトゥエンドヘッダはキャッシュエントリの一部として保存されなければならないし、またキャッシュエントリから形成されたあらゆるレスポンスで転送されなければならない。
- ホップバイホップヘッダ。これは単一の転送レベル接続に対してのみ意味を持ち、キャッシュによって保存されたりプロクシによって転送されたりしないものである。
以下の HTTP/1.1 ヘッダはホップバイホップヘッダである。
- Connection
- Keep-Alive
- Proxy-Authenticate
- Proxy-Authorization
- TE
- Trailers (※)
- Transfer-Encoding
- Upgrade
(※訳注) "Trailer" (section 14.40) の Typo と思われる。
HTTP/1.1 で定義されている他のすべてのヘッダはエンドトゥエンドヘッダである。
HTTP/1.1 (あるいはそれ以降) に導入されるその他のホップバイホップヘッダは、Connection ヘッダにおいて列挙されなければならない (section 14.10)。
ホップバイホップヘッダにおける 単一の転送レベル接続に対してのみ意味を持ち
とは、例えばプロクシを使用している場合に、その先のアプリケーションには転送されないヘッダであるという事です。
下のモデル図をご覧下さい。
ここで、ユーザエージェントは "UA"、オリジンサーバは "O"、プロクシは "P"、単一接続を "v" を表します。
Hop-by-hop Headers ----->
UA ------------v------------ P ------------v------------ O
End-to-end Headers --------------------------------->
すなわち、Connection ヘッダとは、仕様外のホップバイホップヘッダを転送するためのヘッダであるという事ができるのです。 例えば、HTTP/1.1 では未定義である Keep-Alive というヘッダでよく使われます。
言語タグを利用して、レスポンスのエンティティに使用されている自然言語を表すために使用します。 詳しくは、言語タグを含むHTTPの通信シーケンスを参照ください。
Content-Length エンティティヘッダフィールドは、受信者に送られるエンティティボディのサイズを、HEAD メソッドの場合は GET リクエストがなされた場合に送られるエンティティボディのサイズを、10 進数のオクテットで表す。
Content-Length = "Content-Length" ":" 1*DIGIT
例を見よ。
Content-Length: 3495
メッセージボディの大きさを記述するためのフィールドです。 Content-Length はレスポンスヘッダとしてよく見られますが、このヘッダはエンティティヘッダなのでリクエスト時にも使用されます。 例えば、POST リクエスト時にはメッセージボディが必要ですが、この大きさを表すのにも使われます。 但し、メッセージボディに転送コーディングが施されている場合は、メッセージボディの大きさを表すために Content-Length ヘッダを使用してはいけません。 Content-Length の値の決定のために、section 4.4 をご覧下さい。
メッセージの転送長さ{transfer-length} は、それがメッセージの中に現れた時、つまりある転送コーディングが適用された後のメッセージボディの長さである。 メッセージボディがメッセージに含まれる時、そのボディの転送長さは以下のうちのどれかで決定される（優先順位順）。
- メッセージボディを含ん "ではならない"（1xx, 204, 304 レスポンスや HEAD リクエストに対するすべてのレスポンス）レスポンスメッセージは、メッセージ中にエンティティヘッダフィールドがあるか無いかに関わらず、常にヘッダフィールドの後の最初の空行で終了する。
- もし、Transfer-Encoding ヘッダフィールド (section 14.41) があり、"identity" 以外の値を持っていて、接続を閉じる事でメッセージが終了しているのでなければ、転送長さは "chunked" エンコーディング (section 3.6) の使用によって定義される。
- もし、Content-Length ヘッダフィールド(section 14.14) があれば、そのオクテット中の10進数の値は、エンティティ長さ{entity-length} と転送長さを表す。 もしそれら二つの長さが違うのならば、Content-Length ヘッダフィールドを送ってはならない (例えば、Transfer-Encoding がある場合)。 もし、メッセージが Transfer-Encoding ヘッダフィールドと Content-Length ヘッダフィールドとを一緒に送ってきたならば、後者は無視しなければならない。
- もし、メッセージがメディアタイプ "multipart/byteranges" を使い、その転送長さが別の方法で特定できなければ、自身で区切りを持つこのメディアタイプは、その転送長さを定義する。 送信者は、受信者がこのメディアタイプを解析できる事という事を知らないのでならば、使ってはならない。 リクエスト時の複数のバイトレンジを持つ Range ヘッダの存在は、クライアントが multipart/byterange レスポンスを解析できる事を暗黙的に意味する。
multipart/byterange を理解しない HTTP/1.0 プロクシは、Range ヘッダを転送するだろう。 この場合、サーバはこの章で定義されているうちの 1, 3, 5 の項目のいずれかの方法を使って、このメッセージを制御しなければならない。
- 接続を閉じるサーバによる。 （サーバがレスポンスを送り返す可能性がある事を捨て置けないので、リクエストボディの終了を示すために接続を閉じるという方法は、使えない。）
HTTP/1.0 アプリケーションへの互換性のため、メッセージボディを含む HTTP/1.1 リクエストは、もしサーバが HTTP/1.1 に準じている事を知らなければ、適した Content-Length ヘッダフィールドを含まなければならない。 もし、リクエストがメッセージボディを含んでいて、Content-Length を含んでいなかったら、サーバは、それによってメッセージの長さが決定できない場合は 400 (bad request) を、有効な Content-Length を受けとりたい場合は 411 (length required) を、それぞれ返すべきである。
エンティティを受け取るすべての HTTP/1.1 アプリケーションは、"chunked" 転送エンコーディング (section 3.6) を受け入れられなければならないので、メッセージ長が前もって決定できない時には、このメカニズムをメッセージに対して使う事が認められる。
メッセージには、Content-Length ヘッダフィールドと identity でない転送コーディングの両方を含んではならない。 メッセージが、identity でない転送コーディングを含んでいたら、Content-Length は無視されなければならない。
メッセージボディが認められるメッセージにて Content-Length が与えられる時には、そのフィールド値はメッセージボディにおけるオクテットの数と正確に一致しなければならない。 HTTP/1.1 ユーザエージェントは、不正な長さが受信されたり検出された時には、それをユーザに通知しなければならない。
これらをまとめると、以下の様になります。
Content-Location エンティティヘッダフィールドは、エンティティがリクエストされたリソースの URI とは別の場所から取得可能である時に、そのメッセージに含まれるエンティティに対するリソースの場所を与える時に使う事ができる。 サーバは、そのレスポンスエンティティに対応する別種のもの{variant} のための Content-Location を提供すべきである; 特に、それに関連するリソースが複数あり、それらのエンティティが実際に個別にアクセスされ得る別の位置{location} を持っているような場合、サーバは返される特定の別リソース{variant} についての Content-Location を提供すべきである。
Content-Location = "Content-Location" ":" ( absoluteURI | relativeURI )Content-Location の値は、エンティティの基底 URI をも定義する。
Content-Location 値は、本来の Request-URI の代わりとはならない。 すなわち、リクエストの時点でのこの特定のエンティティに対応するリソースの場所を示しているだけである。 もしその特定のエンティティの源を明らかにしたければ、将来のリクエストでは Request-URI として Content-Location の URI を指定する事ができる。
キャッシュは、再利用するために使った URI とは異なる Content-Location を持つエンティティを、その後のその Content-Location URI へのリクエストへのレスポンスとして使ってもよいとは仮定できない。 しかし、section 13.6 に記されているように、Content-Location は単一のリクエストされたリソースから再利用するための複数のエンティティを区別するために使う事ができる。
Content-Location が相対URI であれば、その相対URI は Request-URI から相対的に解釈される。
PUT リクエストや POST リクエストでの Content-Location の意味は定義されていないので、この場合サーバはそれを無視してもかまわない。
Content-Location に似たヘッダに Location ヘッダがありますが、用途は異なります。
Location はリクエストを完了するため、あるいは新しいリソースを識別するため、受信者を Request-URI 以外の場所にリダイレクトする
ために使用されます。
すなわち、リソースを取得するために再び接続し直せという指示を出しているわけです。
これに対し、Content-Location は「今回のリクエストに対して返されるべきこのリソースは、当該フィールド内の URI に存在する」という事を示しているに過ぎません。 より具体的に言えば、これはネゴシエーションへのレスポンスの際に使用されます。 以下をご覧下さい。
GET http://www.studyinghttp.net/example HTTP/1.1 -------------------- HTTP/1.1 200 OK Date: Wed, 08 Mar 2006 00:00:00 GMT Server: Apache/1.3.33 (Win32) Content-Location: example.xhtml Vary: negotiate TCN: choice Connection: close Content-Type: application/xhtml+xml; charset=euc-jp Content-Language: ja Content-Length: 1000
この場合、サーバ内には以下のようなリソースがあったと考えられます。
サーバは、この中から example.xhtml を選び出し、そしてクライアントに返しました。 ここで重要なのは、クライアントがリダイレクトしてそのリソースを取りにいったわけではないという点です。 この点で、Content-Location は Location と大きく異なります。
ある URI から得られるリソースは、常にそこで得られるべきリソースの最新版であるでしょう。 もし、将来において、「今取得したリソースと全く同じもの」が欲しい場合は Content-Location にある URI にアクセスしても良いでしょう。
Content-MD5 エンティティヘッダフィールドは、RFC 1864 [23] にて定義されるように、エンティティボディのメッセージ状態チェック{message integrity check} (MIC) をエンティトゥエンドで提供するという目的を持つエンティティボディの MD5 ダイジェストである。 (注: MIC は転送時における偶発的変化を発見するには有効であるが、故意的攻撃においては十分に対抗はできない。)
Content-MD5 = "Content-MD5" ":" md5-digest md5-digest = <RFC 1864 に従った 128 bit MD5 ダイジェストの base64>Content-MD5 ヘッダフィールドは、オリジンサーバやクライアントがエンティティボディの状態チェックをするために生成する事ができる。 オリジンサーバやクライアントのみが Content-MD5 ヘッダフィールドを生成する事ができ、プロクシやゲートウェイはエンドトゥエンドでの状態チェックという価値が失われてしまうので、これを生成してはならない。 ゲートウェイやプロクシを含むあらゆるエンティティボディの受信者は、このヘッダフィールド内のダイジェスト値が受信したエンティティボディのものと一致するかどうかをチェックする事ができる。
エンティティボディに MD5 というアルゴリズムを適用すると、そのエンティティについてのメッセージダイジェストと呼ばれる、ユニークな文字列を作成する事ができます。 Content-MD5 は、そのようなメッセージダイジェストを記述するためのフィールドです。
範囲リクエスト（部分的GETリクエスト）に対して、部分的レスポンスを返す際のリソースの範囲を記述するためのフィールドです。 詳しくは、部分的レスポンスをご覧ください。
Content-Type エンティティヘッダフィールドは、受信者に送られるエンティティボディのメディアタイプを示し、HEAD メソッドの場合は、GET リクエストがなされた場合に送られるエンティティボディのメディアタイプを示す。
Content-Type = "Content-Type" ":" media-typeメディアタイプは section 3.7 にて定義されている。 このフィールドの使用例を見よ。
Content-Type: text/html; charset=ISO-8859-4
メッセージボディのメディアタイプを記述するためのフィールドです。
実際に利用されているメディアタイプ等の詳しい解説はメディアタイプをご覧下さい。
また、上の例で使用されているcharsetパラメータについては、HTTPで用いられる日本語文字セットも参照ください。
Date 一般ヘッダフィールドは、メッセージが生成された日付・時刻を表し、RFC 822 の
orig-dateと同じ意味論を持つ。フィールド値は、 section 3.3.1 にて示されるHTTP-dateであり、RFC 1123 の時刻フォーマットが送られなければならない。Date = "Date" ":" HTTP-date例を見よ。
Date: Tue, 15 Nov 1994 08:12:31 GMTオリジンサーバは、以下の場合を除き、全てのレスポンスに Date ヘッダフィールドを含めなければならない。
- もし、レスポンスステータスコードが 100 (Continue) か 101 (Switching Protocols) ならば、レスポンスはサーバのオプションとして、Date ヘッダフィールドを含める事ができる。
- もし、レスポンスステータスコードが、例えば 500 (Internal Server Error) や 503 (Service Unavailable) 等のサーバエラーを表せば、有効な Date ヘッダを生成する事は、不便であり不可能である。
- もし、サーバが有効な現在時刻を表せる時計を持っていなければ、レスポンスは Date ヘッダフィールドを含めてはならない。この場合、section 14.18.1 にある規則に従わなければならない。
そのメッセージが作成された時刻を記述するためのフィールドです。 一部の場合を除き、基本的に全てのレスポンスに付加されるべきですが、リクエストの場合も付加することができます。 日付/時刻のフォーマットについては、HTTP日付を参照ください。
Expect リクエストヘッダフィールドは、特定のサーバの振る舞いがクライアントによって要求されている事を示すために使われる。
Expect = "Expect" ":" 1#expectation expectation = "100-continue" | expectation-extension expectation-extension = token [ "=" ( token | quoted-string ) *expect-params ] expect-params = ";" token [ "=" ( token | quoted-string ) ]リクエスト中の Expect フィールドにある期待値{expectation values} を理解できない、あるいはそれに従えないサーバは、適切なエラーステータスを返さなければならない。 サーバは、その期待{expectations} に一つでも添えない場合は、417 (Expectation Failed) ステータスを返さなければならないが、そのリクエストが他に問題を持つような場合などは、他の 4xx ステータスを返してもよい。
このヘッダフィールドは、将来の拡張によって許される拡張された構文によって定義される。 もし、サーバがサポートしていない
expectation-extensionを含んだ Expect フィールドを持つリクエストを受けた時は、417 (Expectation Failed) ステータスを返さなければならない。期待値の比較では、" " にて括られていないトークン (
100-continueトークンも含む) においては大文字・小文字を区別しないが、" " にて括られたexpectation-extensionsにおいては区別される。Expect のメカニズムはホップバイホップである。 すなわち、HTTP/1.1 プロクシは、もし叶えられない期待を持つリクエスト受けた時には 417 (Expectation Failed) ステータスを返さなければならない。 しかし、Expect リクエストヘッダフィールド自体はエンドトゥエンドである。 すなわち、もしリクエストが転送される場合には、このヘッダも転送されなければならない。
多くの古い HTTP/1.0 や HTTP/1.1 各アプリケーションは、Expect ヘッダを理解できない。
100 (continue) ステータスの使い方については、section 8.2.3 参照。
クライアントは、希望する拡張を Expect によって与える事ができます。 HTTP/1.1 では、100 というステータスコードを扱いたいという状況が想定されています。 (逆に言うと、それ以外の Expect 値が定義されていません。)
Expect はホップバイホップ扱いなので、その希望を受け付けられない (あるいはその上流のサーバが受け付けられないと確実に知っている) サーバやプロクシは、直ちに 417 ステータスコードを返さなければなりません。
Expires エンティティヘッダフィールドは、レスポンスが新鮮で無くなる{stale} と考えられる時点の日付/時刻を表す。 通常、キャッシュ (プロクシのキャッシュかユーザエージェントのキャッシュ) は、最初にオリジンサーバ (かエンティティの新鮮なコピーを持つ中間キャッシュ) にその有効性を検証{validated} するまでは、新鮮で無いキャッシュエントリを返さないであろう。 期限切れモデルについて、更に詳しくはsection 13.2 参照。
Expires フィールドがあっても、オリジナルリソースがその期限前、あるいは期限後に更新されたり、削除されたりするという事を暗黙的に意味するものではない。
Expires フィールドのフォーマットは、section 3.3.1 にて定義される絶対日時であり、RFC 1123 の日付フォーマットでなければならない。
Expires = "Expires" ":" HTTP-dateその使用例は以下のようになる。
Expires: Thu, 01 Dec 1994 16:00:00 GMT注: もしレスポンスに
max-age指示子を持つ Cache-Control フィールドを含んでいたら (section 14.9.3 参照) 、その指示は Expires フィールドを上書きする。HTTP/1.1 のクライアントとキャッシュは、今までのように、この他の、特に "0" という値 (すなわち "期限切れ" ) を含む不正な日付フォーマットも扱わなければならない。
レスポンスが "期限切れ" という事を表すためには、オリジンサーバは Date ヘッダの値と同じである Expires の日付を送る (期限の計算方法については、section 13.2.4 参照)。
レスポンスが "期限切れではない" という事を表すためには、オリジンサーバはレスポンスが送られる時点からおよそ1年後の時刻の日付を持つ Expires を送る。 HTTP/1.1 サーバは、Expires の日付に 1 年後以上未来の日付を送るべきではない。
既定ではキャッシュできないレスポンスにおいて、ある未来の日付を持つ Expires ヘッダフィールドがあって、それに Cache-Control ヘッダフィールド (section 14.9) にて何らかの指示がなされていなければ、そのレスポンスはキャッシュ可能である。
そのレスポンスが、いつまで有効かを示すために日付を指定します。 ここに指定する時刻は、HTTP 日付を使用しなければなりません。
サーバが、そのレスポンスのキャッシュを望まない場合は、現時点の時刻 (Date ヘッダの値) を、またしばらくの間十分に有効であるという事を示す場合は 1 年後の値を指定しましょう。
HTTP/1.1 では、Expires や Pragma に含まれる指示子よりも、Cache-Control に含まれるもののほうが優先される事に注意して下さい。
もし From リクエストヘッダフィールドが与えられていれば、そこにはリクエストしているユーザエージェントを操っている人間のインターネット e-mail アドレスが含められているべきである。 そのアドレスは、RFC 1123 によってアップデートされた RFC 822 の中で定義されているような、マシンが使えるものであるべきである。
From = "From" ":" mailbox例を見よ。
From: webmaster@w3.orgこのヘッダフィールドは、ログを取るという目的や不正なあるいは望まないリクエストの原因を究明するために使う事ができる。 アクセス保護の安全性が確保できない形態では使うべきではない。 このフィールドは、このリクエストがそのメソッドを実行する責任を持つ者に代わって実行された、という事を意味する。 特に、ロボットエージェントは、受信後に問題が起きた場合にロボットを操作している責任者に連絡を取るために、このヘッダを含めるべきである。
リクエストを発行するユーザのメールアドレスを通知する時に使用します。 このヘッダは、特にクライアントのうち、特にロボットにて使用されます。
ロボットは、リソースの取得を自動化でき、またその処理も早いなどのメリットがありますが、HTML中のURIが全て同一サーバ内を指すような場合にロボットがリソース取得を行うと、その動作が素早いが故に、そのサーバは短時間に激しいアクセスを受けることになります。 これにより、サーバが一時的な過負荷状態になり、他ユーザがリソースを取得できなくなる可能性があります。 このような問題あるロボットを発見した場合、サイト管理者がロボット運転者に連絡するためのメールアドレスを通知するためのヘッダがFromヘッダです。 したがって、Fromヘッダは、ロボット運転者の明示的な意志なく送信されるべきではありませんが、ロボットを運用するのであればこのヘッダはなるべく送られるべきです。
(※) ロボットによってはメールアドレスをUser-Agentヘッダに含んでいるものもあります。
しかし、不用意にメールアドレスを公開する事はセキュリティ上の観点から問題がある場合があります。 section 15.1.2 をご覧下さい。
From フィールドで送られる情報はユーザのプライバシー観念やサイトのセキュリティポリシーに反するかもしれないので、ユーザがそのフィールドの値を無効、有効、変更ができないのであれば転送されるべきではない。 ユーザは、ユーザ設定やアプリケーションの初期設定においてこのフィールドの内容をセットできなければならない。
必ずというわけではないが、我々はユーザが From と Referer 情報の送信を有効、無効にできるようにする便利なトグルインターフェースを提案する。
上記のようなインターフェースが用意されていない時は、プロクシにてFromヘッダを制御する事になりますが、プロクシを利用したリクエストを発行する場合の注意について、再びsection 14.22をご覧下さい。
このフィールドのインターネット e-mail アドレスは、リクエストを発行するインターネットホストとは異なるものを使う事ができる。 例えば、リクエストがプロクシを通して送られた場合、元々のリクエスト者のアドレスが使われるべきである。
クライアントは、それがユーザのプライバシーへの関心やそのサイトのセキュリティポリシーにそぐわないかもしれないので、From ヘッダフィールドをユーザの承認無しには送るべきではない。 ユーザが、リクエストの前にこのフィールドの値を使用不可にしたり、使用可能にしたり、修正したりできるようする事を強く推奨する。
ロボット運転者の明示的な意志無しにメールアドレスは送信されるべきではありませんが、ロボットを運用するのであれば From ヘッダはなるべく送られるべきです。
Host リクエストヘッダフィールドは、リクエストされたリソースのインターネットホストとポート番号を、ユーザや参照されるリソースによって与えられるオリジナルURI (一般には section 3.2.2 にて表されるような HTTP URL) から得るために、指定する。 Host フィールド値は、オリジンサーバやオリジナルURL によって与えられているゲートウェイによって名付けられる
authorityを表さなければならない。 これによって、オリジンサーバやゲートウェイは、単一の IP アドレス上で複数のホスト名を持つサーバのルートURL "/" のような、内部的に曖昧な{internally-ambiguous} URL を区別する事ができる。Host = "Host" ":" host [ ":" port ] ; Section 3.2.2"
host" の後にポートの情報が無ければ、暗黙的にリクエストされるサービスの既定ポート (すなわち HTTP URL の場合は "80") を使用する事を意味する。 例えば、<http://www.w3.org/pub/WWW/> のオリジンサーバへのリクエストは、厳密には以下のものを含んでいるであろう。GET /pub/WWW/ HTTP/1.1 Host: www.w3.orgクライアントは、すべての HTTP/1.1 リクエストメッセージに Host ヘッダフィールドを含めなければならない。 もし、リクエストされた URI がリクエストされているサービスのインターネットホスト名を含んでいなければ、Host ヘッダフィールドの値は空にしなければならない。 HTTP/1.1 プロクシは、どんな転送するリクエストメッセージにも、プロクシによってリクエストされているサービスを識別する適切な Host ヘッダフィールドを含んでいるようにしなければならない。 すべてのインターネットベースの HTTP/1.1 サーバは、Host ヘッダフィールドが無い HTTP/1.1 リクエストメッセージには、400 (Bad Request) ステータスコードを返さなければならない。
Host は、HTTP/1.1 における唯一の必須ヘッダです。 その理由について、section 19.6.1.1 をご覧下さい。
クライアントとサーバは Host リクエストヘッダをサポートし、HTTP/1.1 リクエストに Host リクエストヘッダ (section 14.23) が欠落していた場合はエラーを知らせ、絶対 URI (section 5.1.2) を受け入れる、という必要条件はこの仕様書にて定義されている最も重要な変更の一つである。
古い HTTP/1.0 クライアントは IP アドレスとサーバの一対一の関係を仮定していたので、そのリクエストが向けられた IP アドレスとは他にリクエストの意図されたサーバを区別するための別の確立されたメカニズムが存在しなかった。 上に概説された変更によって、インターネットは、かつての古い HTTP クライアントはもはや一般的では無い、単一の IP アドレスで複数の Web サイトをサポートできるようになり、単一のホストへの多くの IP アドレスの割り当てが深刻な問題を引き起こしているような、大きな作業上の Web サーバをより簡略化する事ができる。 また、インターネットもルートレベルの HTTP URL 中で使われる特別な目的のドメイン名の唯一の目的に割り当てられていた IP アドレスを取り返す事ができる。Web の成長率と既に設置されたサーバの数を考慮に入れると、全ての HTTP 実装 (既存の HTTP/1.0 アプリケーションを更新したものを含む) がこれらの要求を正しく実装する事は非常に重要である。
- HTTP/1.1 リクエストを送るクライアントは Host ヘッダを送らなければならない。
- クライアントとサーバ共に、Host リクエストヘッダをサポートしなければならない。
- サーバは、HTTP/1.1 リクエストが Host リクエストヘッダを含んでいなければエラー 400 (Bad Request) を知らせなければならない。
- サーバは 絶対URI を受け入れなければならない。
通常、IP アドレスは一台のホストにつき一つ割り当てられるものですが、昨今の急速的な Web の成長による IP アドレスの枯渇が心配されるようになって、一台のホストサーバに複数のドメインを割り当てる事で、まるで複数のホストがあるように振る舞う事ができる機能が開発されました。 このような技術を仮想ホスト(バーチャルホスト)と言い、例えばある一台のホストサーバに host1.studyinghttp.net, host2.studyinghttp.net, host3.studyinghttp.net という三つのドメインを割り当てる事で、まるで三台のホストサーバがあるように見え、これによって IP アドレスを "節約" する事ができるのです。
では、この時に http://host3.studyinghttp.net/hoge へリクエストをするとどうなるでしょうか? クライアントがリソース取得のためにリクエストをする際は、まずホスト名を IP アドレスに変換する、すなわち名前解決をしてサーバを探し出した後、リクエストをするのですが、現在リクエスト先の IP アドレスには三つのホストが "同居" しているので、このままでは望むリソースを上手く取得する事ができません。
そこで、この問題を解決するために使用するヘッダが Host ヘッダ なのです。 section 5.2 をご覧下さい。
インターネットリクエストにより識別された正確なリソースは、 Request-URI と Host ヘッダフィールドの両方で調べる事で決定される。
HTTP/1.1 リクエストによってリソースを決定する時、リクエストされたホストによってリソースが異なるという事を認めていないオリジンサーバは、Host ヘッダフィールド値を無視するであろう。(但し、HTTP/1.1 での Host をサポートする別の必要条件について section 19.6.1.1 参照。)
リクエストされたホストに基づいてリソースを区別する (しばしば仮想ホストや空虚{vanity} なホスト名として参照される) オリジンサーバは、HTTP/1.1 リクエストで要求されたリソースを決定するために以下の規定を使わなければならない。
- もし、 Request-URI が
absoluteURIならば、ホストは Request-URI の一部である。 リクエストにおけるどんな Host ヘッダフィールド値も無視されなければならない。- もし、 Request-URI が
absoluteURIでなく、リクエストが Host ヘッダフィールドを含んでいるならば、ホストは Host ヘッダフィールド値によって決定される。- もし、規則 1 や 2 で決定されるようなホストがそのサーバで正当なホストでないならば、レスポンスは 400 (Bad Request) エラーメッセージでなければならない。
Host ヘッダフィールドが無い HTTP/1.0 リクエストを受信した者は、要求されたリソースがどれほど正確な要求されているかを決定するため (例えば、特定のホストのユニークな何かに対する URI パスの試験のような) 発見方法を試す事ができる。
1 は主にプロクシへのリクエストの場合です。 この場合は、Request-URI 中にホストが含まれていますので、そちらが優先されます。
HTTP の多くのリクエストは 2 の場合です。 この場合、Host ヘッダがないと、仮想ホストが適用されていた場合にリソースを取得する事ができません。 HTTP アプリケーションを作成した時に、400 エラーが返された場合は、Host ヘッダが正しくセットされているかどうかをチェックしてみましょう。
なお、ホスト名が設定されていなかったり、たまたま名前解決できなかったりした場合もありますが、その場合は上にある通り、例えば Host: 192.168.0.1 等とするのでは無く、Host: と、Host ヘッダの値は空にしておきましょう。
If-Modified-Since リクエストヘッダフィールドは、メソッドを条件付きにするために使われる。 もしリクエストされたバリアントがこのフィールドにて指定された時刻以降に更新されていなければ、サーバはエンティティを返す代わりに、304 (not modified) レスポンスをメッセージボディ無しで返すであろう。
If-Modified-Since = "If-Modified-Since" ":" HTTP-dateこのフィールドの例を見よ。
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
指定した時刻以降に更新されているかどうかを尋ねる、条件付き GET を発行する時に使用します。 ここに指定する時刻は、HTTP 日付を使用しなければなりません。
指定した時刻以降に更新されていれば、このヘッダがない時と同じように振る舞いますが、更新されていなければ 304 レスポンスを返さなければならず、その際いかなるレスポンスボディも返してはなりません。
範囲リクエスト（部分的GETリクエスト）発行時に、前回リクエストからリソースが更新されているかどうかを確認するために使用します。 詳しくは、条件付き範囲リクエストをご覧ください。
If-Unmodified-Since リクエストヘッダフィールドは、メソッドを条件付きにするために使われる。 もし、リクエストされたリソースがこのフィールド内に記された時刻以降に更新されていなければ、サーバはそのリクエストに If-Unmodified-Since ヘッダが無い場合と同じようにリクエストされた動作を行うべきである。
リクエストされたバリアントが指定された時刻以降に更新されている場合、サーバはリクエストされた動作を行ってはならない 代わりに、412 (Precondition Failed) を返さなければならない。
If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-dateこのフィールドの使用例は、次のようになる。
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
指定した時刻以降に更新されていないかどうかを尋ねる、条件付き GET を発行する時に使用します。 ここに指定する時刻は、HTTP 日付を使用しなければなりません。
指定した時刻以降に更新されていなければ、このヘッダがない時と同じように振る舞いますが、更新されていれば 412 レスポンスを返さなければなりません。
Last-Modified エンティティヘッダフィールドは、オリジンサーバがバリアントが最後に更新されたと考える日付を表す。
Last-Modified = "Last-Modified" ":" HTTP-date使用例は以下のようになる。
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMTこのヘッダフィールドの正確な意味は、オリジンサーバの実装とオリジナルリソースの性質による。 それがファイルである場合、そのファイルシステムの最終更新時刻になるであろう。 動的に取りこまれる部分を持つエンティティの場合、その各構成要素の最終更新時刻の中で最も最新の物になるであろう。 データベースゲートウェイの場合、レコードの最終更新時刻のタイムスタンプになるであろう。 仮想オブジェクトの場合、内部状態が変化した最終時刻になるであろう。
オリジンサーバは、Last-Modified にメッセージを生成した時刻よりも後の日付を送ってはならない。 リソースの最終更新時刻がある未来の時点を示すような場合は、サーバはその日付をメッセージ生成時点のものに置き換えなければならない。
オリジンサーバは、レスポンスの Date 値を生成する時刻にできるだけ近いエンティティの Last-Modified 値を得るべきである。 これによって受信者は、特にもしエンティティの更新がレスポンスが生成される時刻と近い場合に、エンティティの更新時刻について正確な評価ができる。
HTTP/1.1 サーバは、可能であればいつでも Last-Modified を送るべきである。
リソースの最終更新時刻を記述するためのフィールドです。 ここに指定する時刻は、HTTP 日付を使用しなければなりません。
Last-Modified の意味は、リソースの性質によって変わります。 リソースが単なるファイルであれば "そのファイルの最終更新時刻" という意味でしょうし、CGI 等によって生成される、例えば掲示板等のような動的なデータやデータベースへのゲートウェイの場合には、(CGI スクリプト等の最終更新時刻ではなく) その内部で使用されるデータの最終更新時刻となるでしょう。
Location レスポンスヘッダフィールドは、リクエストを完了するため、あるいは新しいリソースを識別するため、受信者を Request-URI 以外の場所にリダイレクトするのに使われる。 201 (Created) レスポンスの場合、Location はリクエストによって作られた新しいリソースの場所である。 3xx レスポンスの場合、Location はリソースへ自動でリダイレクションさせるためにサーバが望むURIを示すべきである。 このフィールド値は、単一の絶対 URI から成る。
Location = "Location" ":" absoluteURI例を見よ。
Location: http://www.w3.org/pub/WWW/People.html
Locationヘッダは、主に3xxレスポンスに付加されます。 多くのWebブラウザでは、レスポンスにこのヘッダが含まれていた場合、「直ちに」Locationヘッダに記述されたURIへと接続しようとするでしょう。
Locationヘッダを含む通信シーケンスの例として、ディレクトリへのリクエストの際に最後の“/”（スラッシュ）を付けずにリクエストを行う場合をご覧ください。
Max-Forwards リクエストヘッダフィールドは、TRACE (section 9.8) や OPTIONS (section 9.2) の各メソッドに、次のインバウンドサーバにリクエストを転送できるプロクシやゲートウェイの数を制限するというメカニズムを提供する。 これは、クライアントが、その中間で失敗したりループしたりしているリクエスト連鎖を追跡しようとする場合に有用である。
Max-Forwards = "Max-Forwards" ":" 1*DIGITMax-Forwards 値は、このリクエストメッセージが残り何回転送できるかという回数を表す 10 進数の整数値である。
Max-Forwards ヘッダフィールドを含む TRACE あるいは OPTIONS リクエストを受けたプロクシやゲートウェイは、リクエストを転送する前にその値を調べ、更新しなければならない。 もし、受けとった Max-Forwards の値が 0 であれば、受信者はそのリクエストを転送してはならない代わりに、最後の受信者として応答しなければならない。 受けとった Max-Forwards の値が 0 以上であれば、転送されるメッセージにはその値から 1 を引いた値に更新した Max-Forwards フィールドを含めなければならない。
Max-Forwards ヘッダフィールドは、その仕様書で定義された他のすべてのメソッドや、そのメソッド定義の部分で明確に述べられていない拡張メソッド中では無視してもよい。
Max-Forwards を使うと、TRACE や OPTIONS リクエストの際に、転送されるサーバ数を限定する事ができます。 Max-Forwards が 1 以上の時は、次のサーバに転送する際に、そこから 1 を引いた数をセットし直して転送します。 Max-Forwards が 0 の時は、次のサーバに転送せずに、レスポンスを返さなければなりません。
Pragma 一般ヘッダフィールドは、リクエスト/レスポンス連鎖中のあらゆる受信者にも適用されるであろう実装の特別な指示を示すために使われる。 全ての pragma 指示子は、プロトコルの視点から見ればオプショナルな振るまいを指定するが、その振るまいが指示子と一致している事を要求するシステムがあるかもしれない。
Pragma = "Pragma" ":" 1#pragma-directive pragma-directive = "no-cache" | extension-pragma extension-pragma = token [ "=" ( token | quoted-string ) ]
no-cache指示子がリクエストメッセージ中にある時は、アプリケーションはリクエストされたもののキャッシュコピーを持ってたとしても、オリジンサーバに向けてリクエストを転送すべきである。 この pragma 指示子は、no-cacheキャッシュ指示子 (section 14.9 参照) 同じ意味論を持ち、HTTP/1.0 との後方互換のためにここで定義される。 クライアントは、HTTP/1.1 に従っているかどうかを知らないサーバにno-cacheリクエストを送る際には、両方のヘッダフィールドを含めるべきである。pragma 指示子は、そのアプリケーションにとってどんな意味を持つかに関わらず、その指示がそのリクエスト/レスポンス連鎖に関わるすべての受信者に適用されるかもしれないので、プロクシやゲートウェイアプリケーションはそれを無加工で通さなければならない。 特定の受信者のために pragma を指定する可能性は無いけれども、受信者にとって適切で無いあらゆる pragma 指示子は、受信者によって無視されるべきである。
HTTP/1.1 キャッシュは "Pragma: no-cache" を "Cache-Control: no-cache" が送られた時と同様に扱うべきである。 HTTP では、新しい Pragma 指示子は定義されないであろう。
注: レスポンスヘッダフィールドでの "Pragma: no-cache" は、実際には定義されていないので、レスポンスでの "Cache-Control: no-cache" の確実な代用とはならない。
Pragmaヘッダフィールドは、元々 HTTP/1.0 において、サーバへの指示子を持った汎用のHTTPヘッダフィールドとして定義されたものですが、具体的に定義された指示子は no-cache だけです。
この指示子は、文字通りキャッシュしないように指示するものです。
将来、このヘッダに新たな指示子が定義される予定はありません。
HTTP/1.1 では、キャッシュへの指示のために Cache-Control という専用のヘッダフィールドができたので、こちらを使いましょう。 但し、通信する相手の HTTP バージョンがわからない場合は、"Pragma: no-cache" と "Cache-Control: no-cache" の両方を送りましょう。 この場合、HTTP/1.1 アプリケーションは "Cache-Control: no-cache" を優先しますし、HTTP/1.0 アプリケーションは未知の "Cache-Control: no-cache" を無視して "Pragma: no-cache" を適用するでしょう。
範囲リクエスト（部分的GETリクエスト）を行いたい場合に使用します。 詳しくは、一般的な範囲リクエストをご覧ください。
Referer[原文ママ] リクエストヘッダフィールド ("referrer" であるはずなのに綴りは間違っているが) は、サーバの利益のために、 Request-URI が得られたリソースのアドレス (URI) をクライアントに示させる。 Referer リクエストヘッダは、サーバが興味やログの取得、キャッシュの活用等のために、そのリソースへの逆リンクのリストを作成できるようにする。 また、メンテナンスのために、既に使用していない{obsolete} リンクやミスタイプのリンクを追跡できるようにもする。 もし Request-URI が、例えばユーザのキーボードからの入力など、それ自身の URI を持たないソースから得られた場合は、Referer フィールドを送ってはならない。
(中略)
もしこのフィールド値が相対URI ならば、 Request-URI からの相対的なものと解釈すべきである。 URI にはフラグメントを含めてはならない。
参照元、すなわちリンクされている元のリソースの URI を記述するためのフィールドです。 基本的に Referer は送られるべきです。 但し、ブラウザのアドレス欄に URI が打ちこまれたような場合は、参照元となるリソースがありませんので、Referer を送ってはなりません。 また、基本的に Referer は送られるべきですが、クライアントがセキュリティ上の観点から、送るべきではないと判断した場合には送らなくてもかまいません。
しかし、不用意に参照元 URI を公開する事はセキュリティ上の観点から問題がある場合があります。 section 15.1.2, 15.1.3 をご覧下さい。
Referer ヘッダは、読み込み傾向を調査したりやリンクの逆引きをできるようにさせる。 これはとても有用であるが、もしユーザの詳細が Referer に含まれる情報から分けられていなければ、その力は悪用されうる。 さらに個人情報が既に削除されていても、Referer ヘッダは公表が不適当であろうプライベート文書の URI を示すかもしれない。
クライアントは、参照されるページがセキュアプロトコルで転送された場合は、(セキュアで無い) HTTP リクエストに Referer ヘッダフィールドを含むべきではない。
基本的に Referer は送られるべきですが、クライアントがセキュリティ上の観点から、送るべきではないと判断した場合には送らなくてもかまいません。 例えば、SSL 等で保護されるようなページは、実際にはユーザの個人情報やパスワード等が記載されている場合があるので、そのようなページの URI は転送すべきではありません。
しかし、Internet Explorerなどのブラウザでは、自身が送信するRefererヘッダを制御できません。 したがって、このような場合はプロクシを使ってRefererヘッダの値を取り除くことになります。
Retry-After レスポンスヘッダフィールドは、リクエストしているクライアントにそのサービスがどのくらいの時間利用不可能なのかを示すために、503 (Service Unavailable) レスポンスと共に使われる。 また、このフィールドはリダイレクトされたリクエストが発行される前にユーザエージェントが待たなければならない最小の時間を示すために 3xx (Redirection) レスポンスで使う事もできる。 このフィールドの値は、HTTP-date か、あるいはレスポンス時以降の整数の (10進数の) 秒数である。
Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )次の二つの使用例を見よ。
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Retry-After: 120後者の場合、その遅れは 2 分である。
クライアントがどのくらい後にリクエストを再試行すべきかを示すために使用されます。 503 レスポンスと共に使用される場合が一般的です。
オリジンサーバの名前などを記述するためのフィールドです。 ただし、レスポンスがプロクシを経由している場合は、このヘッダではなくViaヘッダにプロクシサーバの名前を追加しなければなりません。
詳細は、サーバの識別情報をご覧ください。
Upgrade 一般ヘッダは、クライアントが他にどんな通信プロトコルをサポートするかを表し、サーバがプロトコルを切り換えた方がいいと判断した場合に使わせたいものを指定させる。 サーバは、Upgrade ヘッダフィールドをプロトコルが切り換えられた事を示す 101 (Switching Protocols) レスポンスの中で使わなければならない。
Upgrade = "Upgrade" ":" 1#product例を見よ。
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
Upgrade ヘッダは、その名の通り、使用されているプロトコルを HTTP/1.1 からアップグレードしたい場合に使用します。 この具体的な使い方については、RFC 2616 を更新した RFC 2817 にて、詳しく記述されています。
まず、クライアントが HTTP/1.1 より「良い」と考えるプロトコルがある場合ですが、これには 2 通りの考え方があります。
クライアントは、セキュアでないレスポンスが受け入れ可能であろう時に、任意の平文 HTTP リクエストの間にセキュアな操作へ切り替えを提案できる。
GET http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1 Host: example.bank.com Upgrade: TLS/1.0 Connection: Upgradeこの場合、サーバは平文の HTTP 操作にて応答する事もできるし、あるいは (次の節で説明されるように) セキュアな操作に切り替える事もできる。
HTTP/1.1 [1] では、"Upgrade が HTTP/1.1 メッセージに存在する時は常に、upgrade というキーワードを Connection ヘッダフィールド (section 14.10) の中に与えなければならない" とされている事に注意せよ。
まずは、プロトコル変更をしたいとは考えるが、実際には HTTP/1.1 でも構わない場合では、通常のリクエストに Upgrade ヘッダを含めます。
これによって、サーバは実際にプロトコル変更をするか、それとも HTTP/1.1 をそのまま使用するのかを選択し、レスポンスにてそれを伝えます。
この時、Connection ヘッダ内に Upgrade というキーワードを入れて、それがホップバイホップヘッダであるという事を明示する必要があります。
セキュアでないレスポンスが受け入れられない場合、クライアントは初めに (可能であれば) TLS/1.0 へと切り替えを完了するために OPTIONS リクエストを送らなければならない。
OPTIONS * HTTP/1.1 Host: example.bank.com Upgrade: TLS/1.0 Connection: Upgrade
もう一つは、どうしてもプロトコル変更を行いたい場合ですが、この場合は OPTIONS メソッドによるリクエストを行わなければなりません。 何故、OPTIONS なのかというと、このメソッドはサーバ上のリソースに対して何らかの動作を行うものではない (no-op な) メソッドであるからです。
サーバは、そのリスト中に使用できるプロトコルがあって、実際に切り替える場合は、そのプロトコル名を Upgrade ヘッダに含めて、101 レスポンスを返します。 (切り替えられない場合は、Upgrade ヘッダがない場合のリクエスト結果に準じます。) このプロトコル変更が有効なのは、現在の接続のみです。
一方、サーバ側も同様に、クライアントにプロトコル変更を要求できるようになっています。 これも 2 通りの考え方があって、まずプロトコル変更をしたいとは考えるが、実際には HTTP/1.1 でも構わない場合では、通常のレスポンスに Upgrade ヘッダを含めるもので、これはリクエストの場合と同様です。 もう一つの、どうしてもプロトコル変更を行いたい場合は、426 というステータスコードを返す事でその意思を示す事ができます。
その名の通り、ユーザエージェントの名前をサーバに示すためのフィールドです。 リクエストがプロクシを経由している場合は、そのプロクシサーバの名前が追加される場合もあります。
詳細は、ユーザエージェントの識別情報をご覧ください。
Vary フィールド値は、そのレスポンスが新鮮である{fresh} 間、キャッシュが再検証無しにそれに続くリクエストに対するレスポンスとして使ってよいかどうかを、完全に決定するためのリクエストヘッダフィールドのセットを示す。 キャッシュできない、あるいは新鮮でなくなった{stale} レスポンスの場合、Vary フィールド値はユーザエージェントにその表現を選択するために使われた基準{criteria} について通知するために使われる。 "*" という Vary フィールド値は、キャッシュはこのレスポンスが適切な表現であるかどうかをそれに続くリクエストのリクエストヘッダからは決定できない、という事を意味する。 キャッシュにおける Vary ヘッダフィールドの使い方については section 13.6 参照。
Vary = "Vary" ":" ( "*" | 1#field-name )HTTP/1.1 サーバは、サーバ駆動型ネゴシエーションを受けるあらゆるキャッシュ可能なレスポンスに Vary ヘッダフィールド値を含むべきである。 そうする事で、キャッシュはそのリソースへの将来のリクエストを適切に解釈する事ができ、ユーザエージェントにそのリソースへのネゴシエーションの存在について知らせる事ができる。 サーバは、サーバ駆動型ネゴシエーションを受けるキャッシュ不可能なレスポンスにも、ユーザエージェントにそのレスポンス時には変化してしまうレスポンスの次元についての有益な情報を提供するであろうから、Vary ヘッダフィールド値を含む事ができる。
Vary ヘッダは、サーバ駆動型ネゴシエーションを実行するのに利用したヘッダのリストを返します。
クライアント-サーバ間で、リクエストを中継したソフトウェアや、その時に使用したプロトコルなどを示すためのHTTPヘッダです。 詳細は、プロクシの識別情報をご覧ください。
HTTP認証において、保護された領域{realm}に入るためには認証が必要であることを示すためのヘッダです。 詳しくは、HTTPアクセス認証のためのHTTPヘッダをご覧下さい。
RFC 2616 にて定義されている HTTP ヘッダは 47 種類ありますが、それ以外の RFC や技術文書によって定義され、利用されている非標準ヘッダもあります。 以下で、その中の代表的なものを解説します。
Content-Dispositionは、本来MIME仕様に従うデータの提示的情報{presentational information} を転送するためのヘッダですが、HTTPはメッセージの形式がMIMEに似ているので、HTMLフォームからマルチパートデータをアップロードする際にも流用されています。 RFC 6266のsection 1をご覧ください。
RFC 2616は、Content-Dispositionレスポンスヘッダフィールド（[RFC2616]のSection 19.5.1）を定義しているが、それはHTTP/1.1標準の一部ではないことを示している（Section 15.5）:
Content-DispositionはHTTP標準では無いが、広く実装されているので、我々は実装者のためにその使用法とリスクについて記述している。
本仕様書は、HTTPにて使用される、Content-Dispositionの定義および登録を引き継ぐ。 既存のユーザエージェント（UA）との相互運用性試験に基づいて、多目的インターネットメール拡張（MIME）のバリアント（[RFC2183]）に定義される特徴の輪郭{profile}を完全に定義し、また国際化についての側面も明確化する。
注: 本書は、メディアタイプ“multipart/form-data”（[RFC2388]）で使用されるような、HTTP上で転送される転送物の中身{payload bodies}に現れるContent-Dispositionヘッダフィールドには適用しない。
RFC 6266の目的は、すでにHTTPで利用されているContent-Dispositionの定義の明確化です。 既存のHTTPの仕様書内の記述については、RFC 2616のsection 19.5.1をご覧ください。
Content-Disposition レスポンスヘッダフィールドは、ユーザがその内容をファイルに保存したい場合にオリジンサーバが既定のファイル名を提案する事を意味するように勧告されている。 この使用法は RFC 1806 中の Content-Disposition の定義に由来する。
content-disposition = "Content-Disposition" ":" disposition-type *( ";" disposition-parm ) disposition-type = "attachment" | disp-extension-token disposition-parm = filename-parm | disp-extension-parm filename-parm = "filename" "=" quoted-string disp-extension-token = token disp-extension-parm = token "=" ( token | quoted-string )例を見よ。
Content-Disposition: attachment; filename="fname.ext"受信するユーザエージェントは
filename-parmパラメータ中に表されているディレクトリパス情報を尊重すべきではない。 その時 HTTP 実装に適用されるために信じられる唯一の情報だからである。 ファイル名は端末構成部品としてのみ扱われるべきである。このヘッダが
content-typeにapplication/octet-streamを持つレスポンス中で使われる場合、ユーザエージェントはレスポンスを表示すべきではなく、直接「レスポンスを名前を付けて保存」ダイアログを記入する事が暗黙的に提案される。
Content-Disposition は本来、MIME 仕様に従うデータの提示的情報{presentational information} を運ぶために作られたヘッダですが、 HTTP はメッセージの形式が MIME に似ているので、HTML フォームからマルチパートデータをアップロードする際にしばしば使用されます。
Content-Disposition ヘッダの filename 属性を使うと、マルチパートデータとして転送されたデータのファイル名をデータの送信側が提示する事ができます。
しかし、このヘッダがセキュリティ上の問題を抱えているという事が section 15.5 に記述されています。
RFC 1806 は、HTTP ではしばしば実装されている Content-Disposition ヘッダについてのものだが、これはいくつかの深刻なセキュリティ上の問題を抱えている。 Content-Disposition は HTTP 標準では無いが、広く実装されているので、我々は実装者にその使用法とリスクについて記述している。 詳細については (RFC 1806 を更新した) RFC 2183 を参照。
ユーザがデータを交換する時はいつでもそれに関係したセキュリティの問題がある。 これらは一つの例を除いて、最小限にされる運命にも無いし、この文書がその評価の中で現状を変える事も無い。
この文書は送信者がファイル名を提示するための方法を提供するので、受信する MUA は送信者の提示するファイル名が危険要素を表していない事に気をつけなければならない。 例として UNIX を使っている場合、いくつかの危険がありうる。
- スタートアップファイルを生成する (例, ".login")。
- システムファイルを生成したり上書きする (例, "/etc/passwd")。
- あらゆる既存のファイルを上書きする。
- 実行ファイルをあらゆるコマンド探査パスに置く(例, "~/bin/more")。
- ファイルをパイプへと送る (例, "| sh")。
一般的に、受信する MUA はユーザの明示的な開始のための動作無しにそれを解釈したり、実行するようなファイルを名付けたり、置いたりすべきではない。
これは網羅的な列挙ではないという事に注目する事は非常に重要である。 すなわちこれはほんの一例に過ぎない。 実装者は目標にするシステム上の潜在的な危険性を警告しなければならない。
Content-Disposition ヘッダの filename 属性を使うと、マルチパートデータとして転送されたデータのファイル名をデータの送信側が提示する事ができます。
当然、受信者側はこの提示されたファイル名を受け入れる必要は無く、自由にファイル名を決定する事ができるのですが、例えばデータの取り扱いになれていない人がこれを扱った場合、誤ってデータを上書きしてしまう可能性があります。
RFC 2183 は、MIME データについてのものなので MUA となっていますが、HTTP クライアントの実装者はこの部分を HTTP クライアントと読み替え、Content-Disposition ヘッダを受け取っても、ユーザの明示的動作を受けない限りは保存ファイル名の決定や、あるいはその実行を自動的に行わせない様に実装しなければいけません。
HTTPにおいて、クッキー{Cookie}とは、元々ユーザエージェント（Webブラウザ）によって保存される「小さな」ファイルを指します。 クッキーは、主に「状態管理」のために利用され、具体的には、たとえばオンラインショッピングでの「ショッピングカート」を実現するために利用されています。 クッキーは、Cookie、及びSet-Cookieという専用のHTTPヘッダを利用することができます。
（※） クッキーは、HTTPヘッダの他にJavaScriptを使っても利用することができます。
クッキーについて、詳しくはHTTP Cookiesをご覧下さい。
HTTP/1.1 では、エンティティヘッダを拡張する事ができます。 すなわち、HTTP/1.1 中に定義されたヘッダを使用する事では表現できないようなメタ情報に関しては、ユーザが任意のヘッダを定義し、送信する事が可能です。
HTTP で使用されるヘッダの形式は、section 4.2 にもある通り、RFC 822 にて定義される形式に由来します。 RFC 822 では、ユーザ定義ヘッダについての項があります。
ネットワークメールの個人の利用者は、追加的ヘッダフィールドを自由に定義・利用できる。 そのようなフィールドはこの仕様書、あるいはあらゆる拡張フィールドの定義の中でまだ使われていない名前がなければならないが、それらユーザ定義フィールドの全体の構文はこの仕様書のフィールド区別と折り重ねの規則を満足しなければならない。 拡張フィールド公開過程によって、ユーザ定義フィールドの名前は先に専有されているかもしれない。
注: "X-" から始まる文字列は、拡張フィールドの名前には使用されない。 これは、保護された名前セットとしてユーザ定義フィールドを提供している。
これをまとめると、以下の様になります。
よって、例えば Author, Copyright, My-Url, X-$$$-Money!, X-#SHARP# 等のヘッダ名を作成する事ができます。
ユーザ定義ヘッダの活用法の一つとして、例えば CGI を使えば、クライアントの送出した HTTP ヘッダを取得できるので、Web サイトを構築している人も活用できるでしょう。 しかし、これらのユーザ定義ヘッダは、クライアントとサーバが互いにその意味を理解していなければいけません。 特に一般的な単語を使ったユーザ定義ヘッダの使用は、同じフィールド名に互いに違う意味を持たせている場合があるかもしれないので、注意が必要となります。
HTTPには様々なパラメータが定義されています。 それらはHTTPヘッダによって、クライアント⇔サーバ間で受け渡しを行っています。 本節では、そのようなHTTPのパラメータについて記述します。
HTTPリクエストにおけるUser-Agentや、HTTPレスポンスにおけるServerでは、内容として製品トークンと呼ばれるものが含まれます。 section 3.8をご覧ください。
製品トークンは、ソフトウェアの名前とバージョンによってその製品である事を識別するアプリケーションと通信する事ができるようにするために使われる。 製品トークンで使用されるほとんどのフィールドは、アプリケーションの重要な部分を形成する部分製品{sub-product} を空白で区切るように列挙できるようになっている。 慣習では、製品はそのアプリケーションを識別するために重要なものの順に列挙される。
product = token ["/" product-version] product-version = token例を見よ。
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 Server: Apache/0.8.4製品トークンは短く要点のみであるべきである。 宣伝や別の本質的でない情報のために使用してはならない。 製品バージョンにはあらゆるトークン文字を使用できるが、このトークンはバージョン識別子に対してのみ使われるべきである。 (例えば、同じ製品の連続したバージョンは、製品値の製品バージョン部分のみが異なるべきである)。
製品トークンに使用できる値はproductまたはcommentです。
これらは、それぞれsection 3.8（product）、および2.2（comment）において、BNFにて定義されており、それ以外の値は使えません。
仕様に違反するような製品トークンを使用した場合、文字化けやフィルタリングなどにより、通信相手に内容が正しく伝わらない可能性があります。
（※） たとえば、User-Agentの仕様違反例はユーザエージェントの識別情報をご覧ください。
HTTPヘッダには日付/時刻を含むものがいくつかありますが、その場合の日付/時刻のフォーマットやHTTP/1.1アプリケーションが日付/時刻を扱う際の注意点については、RFC 2616のsection 3.3.1, 19.3, 19.4.3に記述されています。
HTTP アプリケーションは、歴史的に日付/時刻スタンプの表現のために三つの異なるフォーマットが許されている。
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format最初のフォーマットはインターネット標準としてより好まれ、RFC 1123 (RFC 822 の改訂) にて定義される固定長サブセットを表す。 第二のフォーマットは一般的に使用されているが、時代遅れ{obsolete} な RFC 850 日付フォーマットに基づいており、四桁年号が欠落している。 日付の値を解析する HTTP/1.1 クライアントとサーバは (HTTP/1.0 との互換性のために) 三つすべてのフォーマットを受け入れなければならないが、ヘッダフィールドにおいて HTTP-date 値を表す時は RFC 1123 フォーマットのみを生成しなければならない。 更なる情報については、section 19.3 参照。
注: 日付の値の受取人は、時々 SMTP や NNTP のプロクシ/ゲートウェイを経由してメッセージが回収されたり送信されたりするような場合の時に、非 HTTP アプリケーションによって送られるであろう日付の値を受け入れる程に強固である事が推奨される。
全ての HTTP 日付/時刻スタンプは、例外なくグリニッジ標準時刻 (GMT) で表されなければならない。 HTTP の用途では、GMT は UTC (Coordinated Universal Time) と正確に一致する。 これは、タイムゾーンを表す三文字略として "GMT" の含める事によって最初の二つのフォーマットの中で示され、asctime フォーマットを解釈する時には仮定されなければならない。 HTTP-date は大文字・小文字を区別するが、文法書中の
SPのように、含まれる特定のもの以上の追加的LWSを含んではならない。(中略)
注: この日付/時刻スタンプフォーマットの HTTP 的要求は、プロトコルストリーム内での使用にのみ適用される。 クライアントやサーバは、これらのフォーマットをユーザ提示やログイン要求などのために使用する必要はない。
この文書は HTTP/1.1 メッセージの生成についての要求を表しているものであるが、すべてのアプリケーションが正しくそれらを実装しているわけでは無いであろう。 故に、我々は作業アプリケーションはもし実装から逸脱する部分があってもそれが明確に中間処理できる時は、逸脱に対して寛容である事を推奨する。
(中略)
日付の解析やエンコーディング上の要求や日付エンコーディングに伴うその他の潜在的な問題に対する追加的規則には以下が含まれる。
- HTTP/1.1 クライアントやキャッシュは、将来において 50 年以上現れると思われる RFC-850 日付は実際過去のものであると仮定すべきである (これは "2000年" 問題を解決する助けとなる)。
- HTTP/1.1 実装は解析された Expires 日付を適切な値よりも早いように内部的に表す事ができるが、解析されたExpires を適切な値よりも遅いように内部的に表してはならない。
- 有効期限に関連するすべての計算は、GMT で行われなければならない。ローカルタイムゾーンは経過時間や有効期限の計算や比較に影響を及ぼしてはならない。
- HTTP ヘッダが誤って GMT 以外のタイムゾーンの日付値を転送してしまった場合、最も可能な限り保守的な変換を使って GMT へと変換されなければならない。
HTTP/1.1 は日付比較の処理を簡単にするために制限された日付フォーマット (section 3.3.1) のセットを使用する。 他のプロトコルからのプロクシやゲートウェイは、確実にメッセージ中に与えられるあらゆる Date ヘッダも HTTP/1.1 フォーマットの一つに従い必要であれば日付を書き換えるべきである。
これらをまとめると、以下の様になります。
HTTPヘッダのパラメータとして送ることができる文字集合は、デフォルトではISO-8859-1、すなわちASCIIを8ビットに拡張した文字のみです。 しかし、ISO-8859-1では含まれる文字が限られており、たとえば日本語を送信しようとしても、ISO-2022-JPなどは使用できないため、「使用可能な文字のみで表記する」か、「パーセントエンコーディングなどで使用可能な文字のみにエンコーディングする」といった対応を取るしかありません。
前者は例えば「ローマ字で書く」などの対応になりますが、日本語の読者から見ると著しく可読性が下がります。 また後者では、任意の文字エンコーディングを利用できますが、その場合「受信者はあらかじめ転送される文字セットや言語情報を知っておく必要がある」ことになり、場合によっては正しく文字のデコードが行えずに、文字化けが起こるリスクがあります。
そこで、任意の文字エンコーディングを利用できるようにするために、ハイパーテキスト転送プロトコル（HTTP）ヘッダフィールドのパラメータのための文字セットと言語エンコーディングという文書にてHTTPヘッダのパラメータ部に関する拡張が提案されました。 RFC 5987の拡張を利用すると、ISO-8859-1の他にUTF-8を送信できるようになります。 これにより、たとえばユーロ（€: U+20AC）などのISO-8859-1に含まれない記号や、日本語などの文字も送信できるようになります。
通常のヘッダ > X-Hoge: huga; name="aiu" UTF-8を利用した日本語パラメータを含むヘッダ > X-Hoge: huga; name*=UTF-8'ja'%e3%81%82%e3%81%84%e3%81%86
（※） ただし、現在この拡張を認識できるHTTPアプリケーションはほとんどありません。
, All Rights Reserved.
