14 ヘッダフィールド定義 この章では、すべての標準 HTTP/1.1 ヘッダフィールドのシンタックスとセ マンティクスを定義する。エンティティヘッダフィールドに対して、送信者 と受信者の両方は、クライアントかサーバのどちらかを参照するが、それは エンティティを誰が送信し誰が受信するかに依存する。 14.1 Accept 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 である。 注意: メディアタイプパラメータと Accept 拡張パラメータとを分けるた めに "q" パラメータの名前を使用するのは、歴史的慣例によるものであ る。これによって、メディアレンジとして "q" という名前のパラメータ を使用する事が妨げられるが、IANA メディアタイプ登録機関には "q" パ ラメータは無く、Accept でメディアタイプパラメータを使う事はまれな ので、そのような状況が問題となる事はないと思われる。将来的に、メデ ィアタイプに "q" という名前を持つパラメータが登録される事は推奨さ れない。 次の例を見よ。 Accept: audio/*; q=0.2, audio/basic この例では、「私は audio/basic を望むが、もし品質を 80% 下げても最も 有効に利用できるのであれば、どんな audio タイプでもかまわない」と解釈 される *べきである*。 Accept ヘッダフィールドが無い場合は、クライアントはすべてのメディアタ イプを受けつけるとみなされる。Accept ヘッダフィールドがある場合に、サ ーバが Accpet フィールド値に適したレスポンスを送る事ができなければ、 サーバは 406 (not acceptable) レスポンスを返す *べきである*。 より複雑な例を示す。 Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c これを文字通りに解釈すると、「text/html と text/x-c が望むメディアタ イプであるが、もし存在しないのであれば text/x-dvi エンティティを、そ れも無ければ、text/plain エンティティを送信せよ。」となる。 メディアレンジでは、より特定されるメディアレンジやメディアタイプが優 先される。あるメディアタイプに複数のメディアレンジが当てはまる場合、 最も特定される指示を優先される。例を見よ。 Accept: text/*, text/html, text/html;level=1, */* この優先順位は以下の様になる。 1) text/html;level=1 2) text/html 3) text/* 4) */* あるメディアタイプに関連付けられる品質係数は、そのメディアタイプにマ ッチする最も高い優先度を持つメディアレンジを発見する事によって決定さ れる。例を見よ。 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5 品質係数は以下の様になる。 text/html;level=1 = 1 text/html = 0.7 text/plain = 0.3 image/jpeg = 0.5 text/html;level=2 = 0.4 text/html;level=3 = 0.7 注意: ユーザエージェントは、あるメディアレンジに対してデフォルトの 品質値を供給するかもしれない。しかし、ユーザエージェントが他のレン ダリングエージェントと相互作用できないクローズドなシステムで無いの であれば、このデフォルト値はユーザが設定できるようにすべきである。 14.2 Accept-Charset 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) エラーレスポンスを返す *べきである*。 14.3 Accept-Encoding Accept-Encoding リクエストヘッダフィールドは、Accept ヘッダに似ている が、レスポンスで受け入れ可能な内容コーディング (section 3.5) を制限す る。 Accept-Encoding = "Accept-Encoding" ":" 1#( codings [ ";" "q" "=" qvalue ] ) codings = ( content-coding | "*" ) 使用例は以下の様になる。 Accept-Encoding: compress, gzip Accept-Encoding: Accept-Encoding: * Accept-Encoding: compress;q=0.5, gzip;q=1.0 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 サーバは、Accept-Encoding フィールドに従って、以下のルールを使い内容 コーディングが受け入れ可能かどうかを試す。 1. その内容コーディングが Accept-Encoding フィールドに列挙されてい るうちの一つで、その qvalue が0で無ければ、受け入れ可能である。 (section 3.9 で定義されているように、qvalue が 0 であるという 事は "受け入れ不可能" を意味する。) 2. Accept-Encoding フィールド中の特別な "*" 記号は、ヘッダフィール ド内に明示的に列挙されていないどんな内容コーディングも受け入れ 可能とみなす。 3. もし複数の内容コーディングが受け入れ可能ならば、最も大きな 0 以 外の qvalue を持つ受け入れ可能な内容コーディングが優先される。 4. "identity" 内容コーディングは、もし Accept-Encoding フィールド が "identity;q=0" を含む、あるいは "*;q=0" を含み明示的に "identity" 内容コーディングを含まない事で、特に否定していなけれ ば、常に受け入れ可能である。もし、Accept-Encodingフィールドが空 であれば、"identity" 内容コーディングのみが受け入れ可能である。 リクエストに Accept-Encoding ヘッダがある時に、サーバが Accept- Encoding ヘッダによって受け入れ可能なレスポンスを返せない場合、406 (not acceptable) エラーレスポンスを返す *べきである*。 リクエストに Accept-Encoding フィールドが無い場合は、サーバはどんな内 容エンコーディングも受け入れると仮定する事が *できる*。この場合、もし "identity" が利用可能な内容コーディングの一つで、その他の内容コーディ ングを使う事がクライアントにとって意味のある追加情報となるわけでなけ れば、サーバは "identity" 内容コーディングを使う *べきである*。 注意: リクエストが Accept-Encoding フィールドを含まず、"identity" が利用不可能である場合、古いクライアントの中には他の内容コーディン グと共に送られるメッセージを不適当に表示するものがあるので、 HTTP/1.0 クライアントが一般に理解する内容コーディング (例えば "gzip" や "compress") を使う事が好まれる。サーバは、また特定のユー ザエージェント、あるいはクライアントについての情報に基づく決定を行 ってもよい。 注意: 多くの HTTP/1.0 アプリケーションは、内容コーディングに関連付 けられた qvalue を理解しないし、従わない。これは、qvalue は x-gzip あるいは x-compress については作動しないし許可しない事を意味する。 14.4 Accept-Language Accept-Language リクエストヘッダフィールドは、Accept に似ているが、リ クエストへのレスポンスとして望む自然言語のセットを限定する。言語タグ は、section 3.10 にて定義されている。 Accept-Language = "Accept-Language" ":" 1#( language-range [ ";" "q" "=" qvalue ] ) language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" ) それぞれの languege-range では、そのレンジで指定する言語に対するユー ザの優先度を示す品質値をつける事が *できる*。品質値のデフォルトは、 "q=1" である。例を見よ。 Accept-Language: da, en-gb;q=0.8, en;q=0.7 これは、"私はデンマーク語を望むが、イギリス英語か、他の英語でも受け入 れる。" という事を意味する。もし languege-range が、タグに一致する 時、あるいはタグの接頭辞に等しくてそれに続く文字が "-" である時には、 言語タグに一致する。Accept-Languege フィールドに特別なレンジである "*" がある場合は、その Accept-Languege フィールド内に無いあらゆるタグ に一致する。 注意: この接頭辞一致規則を使うのは、もしユーザがあるタグを持った言 語を理解できるのであれば、そのユーザはこのタグを接頭辞に持つすべて の言語を理解できるはずなので、言語タグをそのような方法で割り当て る、という事を暗に意味するものではない。この接頭辞規則は単に、その ような状況になれば、接頭辞タグを使ってもよいという事である。 Accept-Language フィールドによって言語タグに割り当てられる言語品質係 数は、言語タグに一致するフィールドの中で最も長い languege-range の品 質値である。もしフィールド内に一致するタグが無ければ、割り当てられる 言語品質係数は 0 である。もしリクエストヘッダ内に Accept-Language が 無ければ、サーバはすべての言語が同等に利用可能であるとみなす *べきで ある*。Accept-Language がある場合は、0 以上の品質係数が割り当てられて いるすべての言語が利用可能である。 ユーザが、すべてのリクエストに完全な言語優先度を伴った Accept- Language ヘッダを送信する事は、プライバシー保護の立場とは逆のものとな るかもしれない。この問題の議論について、section 15.1.4 参照。 理解度はそれぞれのユーザへの依存度が高いので、クライアントアプリケー ションはユーザが利用できる言語優先度の選択肢を作る事が薦められる。も しその選択が利用できないように作られているならば、Accept-Language ヘ ッダフィールドをリクエストで与え *てはならない*。 注意: ユーザが利用可能な言語優先度の選択肢を作る時、開発者は、ユー ザは上で記述されているようなものに一致する言語の詳細に精通していな いし、それについて適切な解説を示すべきである、という事を認識すべき である。例えば、"en-gb" を選択したユーザは、もしイギリス英語が利用 できない時は、その他の英語文書が送られて来ると考えるであろう。ユー ザエージェントは、このような場合に最高の一致状態を得るために "en" を加える事を提案できる。 14.5 Accept-Ranges Accept-Ranges レスポンスヘッダフィールドは、サーバにリソースへの範囲 リクエストの受け入れを示させる。 Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges acceptable-ranges = 1#range-unit | "none" バイトレンジリクエストを受け入れるオリジンサーバは、以下のものを送る 事が *できる*。 Accept-Ranges: bytes しかし、これは必ずとも必要ではない。クライアントは、必要とするリソー スに関してこのヘッダを受けなくても、バイトレンジリクエストを生成する 事が *できる*。レンジ単位は、section 3.12 にて定義されている。 リソースへのいかなる範囲リクエストも受け入れないサーバは、以下のもの を送る事が *できる*。 Accept-Ranges: none これは、クライアントに範囲リクエストをしないように忠告する。 14.6 Age Age レスポンスヘッダは、オリジンサーバがレスポンスを生成した (あるい は再検証した) 時点からの送信者の推定経過時間を示す。キャッシュされた レスポンスは、経過時間{age} がその使用有効期限{freshness lifetime} を 過ぎていなければ、新鮮である。Age 値は、section 13.2.3 で記述されたよ うに計算される。 Age = "Age" ":" age-value age-value = delta-seconds Age 値は、負でない整数値であり、秒数を表す。 もしキャッシュが表現できる以上の正の整数値を持っていたり、その経過時 間計算でオーバーフローしたら、2147483648 (2^31) という値の Age ヘッダ を送ら *なければならない*。キャッシュを持っている HTTP/1.1 サーバは、 自身のキャッシュからのすべてのレスポンスにおいて、Age ヘッダフィール ドを含ま *なければならない*。キャッシュは、少なくても 31bit の範囲は ある計算型を使う *べきである*。 14.7 Allow Allow エンティティヘッダフィールドは、Request-URI によって識別される リソースがサポートするメソッドの一覧を示す。このフィールドは、リソー スに関する有効なメソッドを受信者に厳密に知らせる事を目的にする。Allow ヘッダフィールドは、405 (Method Not Allowed) レスポンス中に存在し *な ければならない*。 Allow = "Allow" ":" #Method 使用例を見よ。 Allow: GET, HEAD, PUT このフィールドを使っても、クライアントが他のメソッドを試す事を妨げる 事はできない。しかし、クライアントは Allow ヘッダフィールドにて示され た値には従う *べきである*。実際に許可されるメソッドのセットは、各々の リクエストの度にオリジンサーバによって定義される。 PUT リクエスト時に、Allow ヘッダフィールドを使って、新規、あるいは更 新されるリソースによってサポートされる事が推奨されるメソッドを提供す る事が *できる*。サーバはこれらのメソッドをサポートする事は要求されな いが、レスポンスには実際にサポートされるメソッドを与えた Allow ヘッダ を含める *べきである*。 プロクシは、例えそこに書かれたすべてのメソッドが理解できなくても、ユ ーザエージェントがオリジンサーバと通信するための別の意味を持っている かもしれないので、Allow ヘッダフィールドを書き換え *てはならない*。 14.8 Authorization サーバに認証を受けようとするユーザエージェントは、必ずというわけでは ないが、通常は 401 レスポンスの後、リクエストに Authorization リクエ ストヘッダフィールドを含める。Authorization フィールド値は、リクエス トされたリソースのある領域へのユーザエージェントの認証情報を含む credentials からなる。 Authorization = "Authorization" ":" credentials HTTP アクセス認証については、"HTTP Authentication: Basic and Digest Access Authentication" [43] にて記述されている。もしリクエスト認証さ れ、領域が指定されれば、その領域内への他のすべてのリクエストへも同じ credentials は有効である *べきである* (認証スキーム自身は、例えば challenge 値や使用中の同期した時計によって変更した credentials のよう に、他の場合を要求しない事を仮定する)。 共有キャッシュ (section 13.7 参照) が Authorization フィールドを含む リクエストを受けた時、以下の例外のどれにも当てはまらなければ、他のど んなリクエストへの応答としても対応するレスポンスを返し *てはならな い*。 1. レスポンスが "s-maxage" という cache-control 指示が含んでいる場合 は、キャッシュは、その後のリクエストへの応答にそのレスポンスを使用 して *よい*。しかし (もし指定された最大有効期限が過ぎてしまってい たら) プロクシキャッシュは、オリジンサーバに新しいリクエストを認証 させるために新しいリクエストのリクエストヘッダを使って、始めにオリ ジンサーバで再検証し *なければならない*。 (これは s-maxage のため に定義されている動作である。) レスポンスが "s-maxage=0" を含んでい る場合は、プロクシは (レスポンスのキャッシュを) 再利用する前に常に 再検証し *なければならない*。 2. レスポンスが "must-revalidate" という cache-control 指示を含んでい る場合は、キャッシュはその後のリクエストへの応答にそのレスポンスを 使用して *よい*。しかし、レスポンスが新鮮で無い場合は、すべてのキ ャッシュは、オリジンサーバに新しいリクエストを認証させるために新し いリクエストのリクエストヘッダを使って、始めにオリジンサーバで再確 認し *なければならない*。 3. レスポンスが "public" という cache-control 指示を含んでいる場合 は、キャッシュはその後のどんなリクエストへの応答にもそのレスポンス を使用して *よい*。 14.9 Cache-Control Cache-Control 一般ヘッダフィールドは、リクエスト／レスポンス連鎖上の すべてのキャッシングメカニズムが従わ *なければならない* 指示を記述す るために使用される。キャッシュがリクエストやレスポンスに不利になるよ うに干渉させないような振る舞いを指定する。これらの指示は、常にデフォ ルトのキャッシングアルゴリズムを上書きするものである。キャッシュ指示 は、リクエスト中にある指示があっても、それと同じ指示がレスポンスで与 えられるという事を暗に意味しない、という意味において単向性である。 HTTP/1.0 キャッシュは、Cache-Control を実装してせず、Pragma: no-cache (section 14.32 参照) しか実装していないかもしれない事に 注意せよ。 キャッシュ指示は、リクエスト／レスポンス連鎖上のすべての受信者に適用 できるため、プロクシやゲートウェイアプリケーションを、そのアプリケー ションの重要性に関係なく通り抜け *なければならない*。特定のキャッシュ のために cache-directive を記述するのは不可能である。 Cache-Control = "Cache-Control" ":" 1#cache-directive cache-directive = cache-request-directive | cache-response-directive cache-request-directive = "no-cache" ; Section 14.9.1 | "no-store" ; Section 14.9.2 | "max-age" "=" delta-seconds ; Section 14.9.3, 14.9.4 | "max-stale" [ "=" delta-seconds ] ; Section 14.9.3 | "min-fresh" "=" delta-seconds ; Section 14.9.3 | "no-transform" ; Section 14.9.5 | "only-if-cached" ; Section 14.9.4 | cache-extension ; Section 14.9.6 cache-response-directive = "public" ; Section 14.9.1 | "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1 | "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1 | "no-store" ; Section 14.9.2 | "no-transform" ; Section 14.9.5 | "must-revalidate" ; Section 14.9.4 | "proxy-revalidate" ; Section 14.9.4 | "max-age" "=" delta-seconds ; Section 14.9.3 | "s-maxage" "=" delta-seconds ; Section 14.9.3 | cache-extension ; Section 14.9.6 cache-extension = token [ "=" ( token | quoted-string ) ] ある指示子がどんな 1#field-name パラメータも無く現れた時、その指令は リクエストやレスポンス全体に適用される。ある指示子が 1#field-name パ ラメータを伴って現れたら、指定されたフィールド (群) のみに適用され、 リクエストやレスポンスの残りの部分には適用されない。このメカニズムは 拡張性を持っている。HTTP プロトコルの将来のバージョンのインプリメンテ ーションは、これらの指示子に HTTP/1.1 で定義されていないヘッダフィー ルドを適用する事ができる。 cache-control 指示子は、これらの一般的なカテゴリの中に分類する事がで きる。 - キャッシュ可能なものを制限; これらはオリジンサーバのみが課す事が できる。 - キャッシュによって保存できるものを制限; これらはオリジンサーバか ユーザエージェントのどちらかによって課す事ができる。 - 基本的な満期メカニズムの修正; これらはオリジンサーバかユーザエー ジェントのどちらかによって課す事ができる。 - キャッシュの再検証と再読み込みの制御; これらはユーザエージェント のみが課す事ができる。 - エンティティの変形についての制御。 - キャッシングシステムの拡張。 14.9.1 キャッシュ可能とは何か リクエストメソッド、リクエストヘッダフィールド、レスポンスステータス がキャッシュ可能である事を要求している場合、デフォルトではレスポンス はキャッシュ可能である。section 13.4 では、キャッシュ可能性のためのこ れらのデフォルトを要約している。以下の Cache-Control レスポンス指示子 を使うと、オリジンサーバはレスポンスのデフォルトのキャッシュ可能性を 上書きする事ができる。 public たとえそれが通常はキャッシュ可能でなかったり、非共有キャッシュ内で のみキャッシュ可能であったとしても、レスポンスがすべてのキャッシュ によってキャッシュ可能に *できる* 事を示す。 (追加される詳細のた め、section 14.8 の Authorization も見よ。) private レスポンスメッセージのすべてもしくは一部は、単一のユーザのために用 意された物であり、共有キャッシュによってキャッシュされ *てはならな い* 事を示す。これによって、オリジンサーバは、そのレスポンスの指定 された部分ががあるユーザにのみ向けられたもので、別のユーザによるリ クエストにとっては正当なレスポンスではない事を述べる事ができるよう にする。プライベート (非共有) キャッシュは、そのレスポンスをキャッ シュ *できる*。 注意: この private と言う指示子の使用は、レスポンスがキャッシュで きるところのみを制御するもので、メッセージ内容のプライバシーは保 証できない。 no-cache もし no-cache 指示子がフィールド名を指定していなければ、オリジンサ ーバへの再検証が成功するまで、以降のリクエストを満足させるためにそ のレスポンスを使っ *てはならない*。これによって、オリジンサーバは リクエストするクライアント古くなったレスポンスを返すよう設定されて いるキャッシュによるキャッシングさえ行えなくする事ができる。 もし no-cache 指示子が一つ以上のフィールド名を指定していたら、キャ ッシュはキャッシングにおける他の制約の元で、以降のリクエストを満足 するためにそのレスポンスを使う事が *できる*。しかし、指定されたフ ィールド名はオリジンサーバへの再検証が成功するまで、以降のリクエス トを満足させるためにそのレスポンスを使っ *てはならない*。これによ って、オリジンサーバはレスポンスの残りをキャッシングできる間、レス ポンス中のあるヘッダフィールドの再使用を行えなくする事ができる。 注意: 多くの HTTP/1.0 キャッシュは、この指示子を理解できず、従う 事はないだろう。 14.9.2 キャッシュによって保存できるものは何か no-store no-store 指示子の目的は、取り扱いが慎重な (例えばバックアップテー プ上の) 情報の不注意な漏洩や保留を防ぐ事である。no-store 指示子は メッセージ全体に適用され、レスポンスかリクエストのどちらかで送るこ とが *できる*。リクエストで送られる場合、キャッシュはそのリクエス トやそれへのいかなるレスポンスの一部分を保存し *てはならない*。レ スポンスで送られる場合、キャッシュはそのレスポンスやそれを引き起こ したリクエストの一部分を保存し *てはならない*。この指示は、非共有 ・共有キャッシュのどちらにも当てはまる。この状況下での "保存しては *ならない*" は、キャッシュを一時的なものではない保存場所{non- volatile storage} にその情報を故意に保存し *てはならない* し、一時 的な保存場所{volatile storage} であってもそれを転送した後にできる だけ早くそこから情報の削除するために最善を尽くさ *なければならな い*、という事を意味する。 その指示がレスポンスに関連している時でも、ユーザはキャッシングシス テムの外側にそのようなレスポンスを明白に (例えば、"Save As" ダイア ログを伴って) 保存できる。履歴バッファは、これらの通常操作の一部と してこのようなレスポンスを保存する事が *できる*。 この指示の目的は、キャッシュデータ構造への予期しないアクセスを経て 情報の偶発的な漏洩を心配するユーザやサービス著者達が前もって示した 必要条件に見合うようにするためである。この指示子を使う事でいくつか の場合でプライバシーを改善できるであろうが、これはプライバシーを保 証するための信頼できる、もしくは十分なメカニズムのどのような方法に おけるものでは *無い* 事を警告しておく。特に、悪意のあるキャッシュ や一部の機能のみが実装された{compromised} キャッシュはこの命令を認 識しなかったり従わなかったりするかもしれないし、あるいは通信ネット ワーク自体が盗聴に対して無防備であるかもしれない。 14.9.3 基本的な期限のメカニズムの修正 エンティティの有効期限は、Expires ヘッダ (section 14.21 参照) を使っ てオリジンサーバにより記述する事が *できる*。あるいは、レスポンスで max-age 指示子を使って記述する事が *できる*。max-age cache-control 指 示子がキャッシュされたレスポンス中にあった時に、現在まで経過した時間 {age} がそのリソースへ新しいリクエストがなされてからの (秒数で) 与え られた時間を過ぎていたら、そのレスポンスは新鮮では無い。レスポンス中 の max-age 指示子があり、その他にキャッシュに制限を与えるような指示子 が無ければ、レスポンスはキャッシュ可能 (すなわち、"共有キャッシュ") であるという事を暗黙的に意味する。 もしレスポンスに Expires ヘッダと max-age 指示子の両方が含まれたいた ら、たとえ Expires ヘッダがより制限的なものであっても、max-age 指示子 は Expires ヘッダを上書きする。このルールによって、オリジンサーバは与 えられたレスポンスに対して HTTP/1.0 キャッシュよりも HTTP/1.1 (及びそ れ以降の) キャッシュに長い有効期限を提供できるようになる。これは、あ る HTTP/1.0 キャッシュがおそらく同期していない時計のために不適当に経 過時間や有効期限を計算してしまうような場合に有用であろう。 多くの HTTP/1.0 キャッシュインプリメンテーションは、Cache-Control レ スポンス指示子が "no-cache" と同等であるようなレスポンスの Date 値以 下として Expires 値を扱うであろう。もし HTTP/1.1 キャッシュがそのよう なレスポンスを受けとり、そのレスポンスが Cache-Control ヘッダフィール ドを含んでいなければ、そのレスポンスは HTTP/1.0 サーバとの互換性を保 つためにキャッシュ可能ではないとみなす *べきである*。 注意: オリジンサーバは、例えば "private" 指示子のような、比較的新 しい HTTP キャッシュコントロール機能を、その機能を理解しない古い キャッシュを含むネットワーク上で使いたいとするかもしれない。オリ ジンサーバは、その値が Date 値以下になるような Expires フィールド を新しい機能を結合する必要があるであろう。これによって、古いキャ ッシュにレスポンスを不適当にキャッシングさせないようにするであろ う。 s-maxage レスポンスが s-maxage 指示子を含んでいる場合、共有キャッシュにつ いて (非共有キャッシュについてではない) 、この指示子で指定された 最大使用期限は max-age 指示子や Expires ヘッダによって指定された 最大使用期限を上書きする。また s-maxage 指示子は proxy-revalidate 指示子 (section 14.9.4 参照) のセマンティクス、すなわち、共有され たキャッシュはオリジンサーバに最初の再検証をせずにその後のリクエ ストへのレスポンスとしてそれが新鮮で無くなってしまったエントリを 使ってはならない、という事も暗黙的に意味する。s-maxage 指示子は、 非共有キャッシュには常に無視される。 多くの古い、この仕様書に従わないようなキャッシュは、いかなる cache- control 指示子も実装していない事に注意せよ。HTTP/1.1 に従順なキャッシ ュによるキャッシングを制限し、同時にそれを邪魔しない、cache-control 指示子を使いたいオリジンサーバは、max-age 指示子は Expires ヘッダを上 書きするという条件と、HTTP/1.1 に従順なキャッシュ以前のものは max-age 指示子に気付かないという事実を利用する事が *できる*。 他の指示子は、ユーザエージェントが基本的な期限メカニズムを修正できる ようにする。これらの指示は、リクエストにおいて記述 *できる*。 max-age クライアントは、ここで記述した秒時間よりも大きな経過時間を持たない ようなレスポンスを受け入れる意図を持つ事を表す。そこに max-stale 指示子が含まれていなければ、クライアントは古くなったレスポンスを受 け入れようとはしていない。 min-fresh クライアントは、それが新鮮であるような残り時間がここで指定した秒時 間に現在の経過時間を足した物より小さくなるようなレスポンスを受け入 れる意図を持つ事を表す。これは、クライアントが少なくとも指定した秒 数の間はまだ新鮮であるようなレスポンスを望んでいるという事である。 max-stale クライアントは、期限を超えたようなレスポンスを受け入れる意図を持つ 事を表す。max-stale に値を割り当てられている場合、クライアントは指 定した秒数だけ有効期限を過ぎてしまったようなレスポンスを受け入れよ うとしている。max-stale に値が割り当てられていない場合は、クライア ントはどれだけ時間が経過しような新鮮で無いレスポンスも受け入れよう としている。 リクエスト中の max-stale 指示子、あるいはキャッシュがレスポンスの有効 期限を上書きするように形成されているかのどちらかの理由で、キャッシュ が新鮮でないレスポンスを返す場合、キャッシュは Warning 110 (Response is stale) を使って、新鮮ではないレスポンスに Warning ヘッダを追加し *なければならない*。 キャッシュは、キャッシュの再検証に関しての "MUST" レベルの必要条件 (例えば "must-revalidate" cache-control 指示子) とは矛盾を起こさない ようにする場合のみ、再検証せずに新鮮で無いレスポンスを返すように構成 する事が *できる*。 もし新しいリクエストとキャッシュされたエントリの両方に "max-age" 指示 子が含まれていたら、そのリクエストのためのキャッシュされるエントリの 残り時間の決定には、二つの値の小さい方が使われる。 14.9.4 キャッシュの再検証とリロードコントロール 時々ユーザエージェントは、キャッシュがオリジンサーバ (オリジンサーバ への経路上の次のキャッシュではなく) にキャッシュエントリの再検証を行 う事を要求したり、オリジンサーバからそのキャッシュエントリをリロード する事を望みあるいは必要とするかもしれない。エンドトゥエンド{end-to- end} 再検証は、キャッシュかオリジンサーバのどちらかがキャッシュされた レスポンスの有効期限を過大評価している場合に必要とあろう。エンドトゥ エンド・リロードは、キャッシュエントリがある理由のため古く使えなくな った場合に必要とあろう。 エンドトゥエンドの再検証は、クライアントが自身のローカルにキャッシュ されたコピーを持っていないような、我々が "未指定性エンドトゥエンド再 検証{Unspecified end-to-end revalidation}" と呼ぶような場合か、クライ アントがローカルにキャッシュされたコピーを持っているような、我々が "指定性エンドトゥエンド再検証{Specific end-to-end revalidation}" と呼 ぶような場合の、どちらかの場合で要求されるであろう。 クライアントは、Cache-Control リクエスト指示子を使って以下の三種類の 動作を指定する事ができる。 エンドトゥエンド・リロード リクエストは、"no-cache" Cache-Control 指示子や、HTTP/1.0 クライア ントとの互換性のための "Pragma: no-cache" を含んでいる。リクエスト 中には、no-cache 指示子を伴うどんなフィールド名も含ん *ではならな い*。サーバは、そのようなリクエストに応答する時にはキャッシュされ たコピーを使っ *てはならない*。 指定性エンドトゥエンド再検証 リクエストは、"max-age=0" Cache-Control 指示子を含み、これは強制的 に自身のエントリの正当性をオリジンサーバや、もしあればオリジンサー バへの経路上のそれぞれのキャッシュに再検証させる。最初のリクエスト では、クライアントの現在のバリディタを伴うキャッシュの正当性検証条 件{cache-validating conditional} を含んでいる。 未指定性エンドトゥエンド再検証 リクエストは、"max-age=0" Cache-Control 指示子を含み、これは強制的 に自身のエントリの正当性をオリジンサーバや、もしあればオリジンサー バへの経路上のそれぞれのキャッシュに再検証させる。最初のリクエスト では、クライアントの現在のバリディタを伴うキャッシュの正当性検証条 件を含んでいない。このリソースのキャッシュエントリを持っている経路 上の最初のキャッシュ (もしあれば) は、現在のバリディタを伴うキャッ シュの正当性検証条件を含んでいる。 max-age 中間キャッシュが max-age=0 によって、そのキャッシュエントリの再確 認を強制され、クライアントがそのリクエスト中に自身のバリディタを 供給するような場合、供給されたバリディタは現在キャッシュエントリに 保存されているバリディタとは異なるかもしれない。この場合、キャッシ ュは意味的透過性の影響を考える事無くそれ自身のリクエストを作成する 際にはどちらのバリディタでも使う事が *できる*。 しかし、バリディタの選択によってパフォーマンスに影響が出るかもしれ ない。中間キャッシュがリクエストを作成する際の最良のアプローチは、 自身の確証子を使う事である。サーバが 304 (Not Modified) を返した場 合は、キャッシュはクライアントに 200 (OK) レスポンスと現在の検証さ れたコピーを返す事ができる。しかし、もしサーバが新しいエンティティ とキャッシュバリディタを返したら、中間キャッシュは返されたバリディ タとクライアントのリクエストから与えられたものとを強い比較機能を使 使用して比較する事ができる。クライアントのバリディタがオリジンサー バのものと等しければ、中間キャッシュは単純に 304 (Not Modified) を 返す。そうでなければ、200 (OK) レスポンスと新しいエンティティを返 す。 リクエストが no-cache 指示子を含む場合は、min-fresh, max-stale, max-age を含む *べきではない*。 only-if-cached 例えばネットワーク接続が極めて貧弱である等、いくつかの場合では、ク ライアントはキャッシュが現在保存しているレスポンスのみを返し、オリ ジンサーバにリロードや再検証を行わないように望むだろう。これを行う ため、クライアントはリクエスト中に only-if-cached 指示子を含む事が できる。この指示子を受け取った場合、キャッシュはそのリクエストの別 の条件を満たすようなキャッシュエントリを使って返すか、504 (Gateway Timeout) ステータスを返すか、どちらかを行う *べきである*。しかし、 もしあるキャッシュのグループが内部の接続性が良い統合システムとして 運用されているなら、そのようなリクエストはそのようなキャッシュのグ ループ内に転送しても *よい*。 must-revalidate キャッシュはサーバの指定する有効期限を無視するように形成する事が *でき*、またクライアントのリクエストでは max-stale 指示子を含む事 が *できる* (これは似たような効果がある) ので、プロトコルはオリジ ンサーバがそれ以降に使われるあらゆるキャッシュエントリの再検証を要 求するようなメカニズムを含む。must-revalidate 指示子がキャッシュに よって受信されたレスポンス中にあった時は、キャッシュはオリジンサー バに最初にそれを再検証せずに以降のリクエストに応答するために新鮮で 無いエントリを使っ *てはならない*。 (すなわち、キャッシュは毎回エ ンドトゥエンドの再検証をし *なければならない* し、もし、単にオリジ ンサーバの Expires か max-age 値に基づいているなら、キャッシュされ たレスポンスは新鮮なものではない。) must-revalidate 指示子は、特定のプロトコル機能の信頼できる操作をサ ポートするために必要である。いかなる状況においても HTTP/1.1 キャッ シュは must-revalidate 指示子には従わ *なければならない* が、特別 に、もしキャッシュが何らかの理由でオリジンサーバに到達できない場合 は、504 (Gateway Timeout) レスポンスを生成し *なければならない*。 例えば黙って履行されていない財務的処理{silently unexecuted financial transaction} のように、エンティティの再検証が失敗するこ とでリクエストが不適当な操作というような結果になる場合にのみ、サー バは must-revalidate 指示子を送る *べきである*。受信者は、この指示 を破るような自動的動作は行っ *てはならない* し、もし再検証に失敗し たらエンティティの検証が行われていないコピーを自動的に供給し *ては ならない*。 これは奨励されないが、厳しい接続制約の元で操作されているユーザエー ジェントはこの指示を破る事が *できる* が、そのような場合でも、検証 されていないレスポンスが供給された事をユーザに明確に警告し *なけれ ばならない*。この警告は、検証されていないアクセス毎に供給され *な ければならない* し、ユーザによる明確な検証を必要とす *べきであ る*。 proxy-revalidate proxy-revalidate 指示子は、非共有ユーザエージェントキャッシュには 適用されない事を除けば、must-revalidate 指示子と同じ意味を持つ。こ れは、多くのユーザにサービスしているプロクシは毎回再検証する事を必 要とする (それぞれのユーザが認証されている事を保証するため) 一方 で、ユーザのキャッシュにそれを再検証する必要が無いレスポンス (ユー ザによって既に一度認証されているので) を保存し、後に返すような事を 許すような認証リクエストへのレスポンスとして使用できる。 そのような認証されたレスポンスも、それらがすべてキャッシュされるよ うにするためには public キャッシュコントロール指示子を必要とする事 に注意せよ。 14.9.5 no-transform 指示子 no-transform 中間キャッシュ (プロクシ) の実装者は、あるエンティティボディのメデ ィアタイプを変換する事が有用である事を知っている。例えば、透過的プ ロクシはキャッシュスペースを節約したり、遅い通信路上のトラフィック の量を減らすために画像フォーマットの変換を行う事ができる。 しかし、これらの変換がある種のアプリケーションのために作られたエン ティティボディに適用される時に、深刻な操作上の問題が起こる事があ る。例えば、医療用の映像処理、科学的なデータ分析、およびエンドトゥ エンド認証を使うようなアプリケーションは、すべて元々のエンティティ ボディと bit 単位で同一のエンティティボディを受け取る事を前提にし ている。 それ故に、もしメッセージが no-transform 指示子を含んでいたら、中間 キャッシュやプロクシは no-transform 指示に従うものとして section 13.5.2 で列挙されているようなヘッダを変更し *てはならない*。これ は、キャッシュやプロクシがこれらのヘッダによって指定されたエンティ ティボディの、エンティティボディ自身の値を含め、いかなる部分も変更 し *てはならない* 事を意味する。 14.9.6 キャッシュコントロールの拡張 Cache-Control ヘッダフィールドは、それぞれにオプション的に割り当てら れる値を伴う、一つ以上の cache-extension トークンを使う事によって拡張 可能である。情報的拡張 (キャッシュの振る舞いにおける変更を必要としな いもの) は、他の指示子のセマンティクスを変更せずに追加 *できる*。振る 舞いの拡張は、既存のキャッシュ指示子のベースへの修飾子として動作する 事により機能するために設計されている。新しい指示子と標準の指示子が与 えられる場合、新しい指示子を理解しないアプリケーションは標準の指示子 によって指定される振る舞いをデフォルトとし、新しい指示子を理解するよ うなアプリケーションは標準命令に関連する要求点を修正するようにそれを 認識する。このようにして、Cache-Control 指示子はその基底のプロトコル を変更する必要なく拡張する事ができる。 この拡張メカニズムは、それに元々の HTTP バージョンによって定義される すべての cache-control 指示子に従い、ある特定の拡張にも従い、理解でき ない指示子はすべて無視するような HTTP キャッシュに依存する。 例えば、ここで private 指示子の修飾子として動作する "community" と呼 ばれる新しいレスポンス指示子を仮定する。この新しい指示子を、あらゆる 非共有キャッシュに加えて、この値で名前付けされたコミュニティのメンバ によってのみ共有されるあらゆるキャッシュはそのレスポンスをキャッシュ できる、と定義する。UCI というコミュニティに元々プライベートレスポン スであるものを共有キャッシュとして使わせようとするオリジンサーバは、 以下のものを含む事でそうする事ができる。 Cache-Control: private, community="UCI" このヘッダフィールドを認識するキャッシュは、例え community というキャ ッシュ拡張を理解しなくても、private 指示子を見つけ理解する事で、安全 な振る舞いをデフォルトとするので正しく動作するだろう。 認識できないキャッシュ指示子は、無視され *なければならない*。つまり、 HTTP/1.1 キャッシュには理解されないであろうあらゆるキャッシュ指示子は 例えキャッシュが拡張を理解できないとしてもキャッシュの振る舞いが最小 限正しいものであるように、標準の指示子 (やレスポンスのデフォルトのキ ャッシュ能力) と結合され送られるという事が仮定される。 14.10 Connection Connection 一般ヘッダフィールドは、送信者が特定の接続のために望むオプ ションを指定する事を可能にするが、介在するプロクシとの接続を超えて伝 達し *てはならない*。 Connectionヘッダは、以下の様な文法を持つ。 Connection = "Connection" ":" 1#(connection-token) connection-token = token HTTP/1.1 プロクシは、メッセージが転送される前に Connection ヘッダフィ ールドを解析し、フィールド内の各 connection-token ごとに、connection- token と同じ名前を持つメッセージからヘッダフィールドを削除し *なけれ ばならない*。接続オプションは、その接続オプションに関するパラメータが 無ければ、追加的ヘッダフィールドは送信されないかもしれないので、対応 する追加的ヘッダフィールドによってではなく、Connection ヘッダフィール ド内の connection-token によって表される。 Connection ヘッダ内に列挙されるメッセージヘッダは、Cache-Control のよ うなエンドトゥエンドヘッダを含め *てはならない*。 HTTP/1.1 では、送信者がレスポンスを完了した後に接続を切断するというこ とを合図する "close" 接続オプションを定義する。次の例を見よ。 Connection: close この場合、リクエスト・レスポンスのどちらかのヘッダフィールドの場合で も、その接続は現在のリクエスト／レスポンスが完了したら、「持続的」 (section 8.1) であるとみなす *べきではない*。 持続的接続をサポートしていない HTTP/1.1 アプリケーションは、すべての メッセージに "close" 接続オプションを含め *なければならない*。 Connection ヘッダを含む HTTP/1.0 (あるいはそれ以前の) メッセージを受 けとったシステムは、このフィールド内の各 connection-token ごとに、 connection-token と同じ名前を持つメッセージからヘッダフィールドを削除 し、無視し *なければならない*。これは、HTTP/1.1 以前のプロクシによっ てそのようなヘッダフィールドを転送するような誤りを起こさないようにす るものである。section 19.6.2 参照。 14.11 Content-Encoding Content-Encoding エンティティヘッダフィールドは、メディアタイプの修飾 子として使われる。この値があれば、それはエンティティボディに適用され ている内容コーディングを示し、すなわち Content-Type ヘッダフィールド にあるメディアタイプを得るために適用しなければならないデコード方法を 示している。内容コーディングは、主にその根底のメディアタイプの特性を 失わせる事無く文書を圧縮するために使われる。 Content-Encoding = "Content-Encoding" ":" 1#content-coding 内容コーディングは、section 3.5 にて定義されている。使用例を見よ。 Content-Encoding: gzip 内容コーディングは、Request-URI によって識別されるエンティティの特性 である。一般に、エンティティボディは、このエンコーディング状態のまま 保存され、レンダリングやそれに類似した使用の直前にのみデコードされ る。しかし、透過的でないプロクシは、受信者がそれ以外のコーディングが 利用可能であると知っていて、かつメッセージ中に "no-transform" cache- control 指示子が無い時は、内容コーディングを修正する事が *できる*。 エンティティの内容コーディングが "identity" で無い場合、レスポンスは 現在使用されている identity で無い内容コーディング (複数可) を列挙し た、Content-Encoding エンティティヘッダ (section 14.11) を含め *なけ ればならない*。 もしリクエストメッセージ中のエンティティの内容コーディングをオリジン サーバが利用できなければ、サーバは 415 (Unsupported Media Type) のス テータスコードを持つレスポンスを返す *べきである*。 エンティティに複数のエンコーディングが適用されている場合は、それが適 用された順に列挙され *なければならない*。エンコーディングパラメータに ついての追加情報は、この仕様書では定義されない他のエンティティヘッダ フィールドによって与える事が *できる*。 14.12 Content-Language Content-Language エンティティヘッダフィールドは、それと共に送られるエ ンティティの読者の自然言語を表す。ただし、エンティティボディで使われ ている言語のすべてとは一致しないかもしれない事に注意せよ。 Content-Language = "Content-Language" ":" 1#language-tag 言語タグは、section 3.10 にて定義されている。Content-Language の主な 目的は、ユーザ自身が望む言語に応じて、エンティティを識別したり区別し たりできるようにするためである。そのため、もしボディの内容がデンマー ク語を理解できる人のみを対象にしているのならば、それに合ったフィール ドは次のようになる。 Content-Language: da Content-Language が特定されていない場合、デフォルトではその内容は全て の言語読者に向けられている、という事になる。これは、送信者はそれがい ずれかの自然言語に特有のものであるとは考えていないか、あるいは送信者 自身がどの言語を意図しているかがわからないか、のどちらかを意味するで あろう。 複数の言語の読者を対象とした内容では、複数の言語を列挙する事が *でき る*。例えば、オリジナルのマオリ語版と英語版が同時に表現される "ワイタ ンギ条約" の翻訳では、以下の様に表されるだろう。 Content-Language: mi, en しかし、エンティティ内に複数の言語があるという事が、すなわち複数の言 語の読者を対象にしているとは限らない。例えば、"初めてのラテン語" のよ うなその言語の初心者向け読み物がその例で、これは明らかに英語を理解す る読者に向けられている。この場合、Content-Language は適切に "en" のみ を含めるべきである。 Content-Language は、テキスト文書だけでなく、あらゆるメディアタイプに 適用する事が *できる*。 14.13 Content-Length Content-Length エンティティヘッダフィールドは、受信者に送られるエンテ ィティボディのサイズを、HEAD メソッドの場合は GET リクエストがなされ た場合に送られるエンティティボディのサイズを、10 進数のオクテットで表 す。 Content-Length = "Content-Length" ":" 1*DIGIT 例を見よ。 Content-Length: 3495 アプリケーションは、section 4.4 にある規則で禁じられていなければ、こ のフィールドをメッセージボディの転送長さを示すのに使う *べきである*。 0 以上の値を持つ Content-Length は、すべて有効値である。section 4.4 では、Content-Length が与えられていない場合のメッセージボディの長さを 決定する方法を記している。 このフィールドの意味は、MIME にて対応する定義、すなわち "message/external-body" という content-type の中で使われるオプショナ ルなフィールドとは全く異なっている事に注意せよ。HTTP では、section 4.4 にある規則で禁じられていなければ、メッセージを転送する前にその長 さを決定できる時は常にそれを送る *べきである*。 14.14 Content-Location Content-Location エンティティヘッダフィールドは、エンティティがリクエ ストされたリソースの URI とは別の場所から取得可能である時に、そのメッ セージに含まれるエンティティに対するリソースの場所を与える時に使う事 が *できる*。サーバは、そのレスポンスエンティティに対応する、別種のも の{variant} のための Content-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 の意味は定義さ れていないので、この場合サーバはそれを無視してもかまわない。 14.15 Content-MD5 Content-MD5 エンティティヘッダフィールドは、RFC 1864 [23] にて定義さ れるように、エンティティボディのメッセージ状態チェック{message integrity check} (MIC) をエンティトゥエンドで提供するという目的を持つ エンティティボディの MD5 ダイジェストである。 (注意: MIC は転送時にお ける偶発的変化を発見するには有効であるが、故意的攻撃においては十分に 対抗はできない。) Content-MD5 = "Content-MD5" ":" md5-digest md5-digest = Content-MD5 ヘッダフィールドは、オリジンサーバやクライアントがエンテ ィティボディの状態チェックをするために生成する事が *できる*。オリジン サーバやクライアントのみが Content-MD5 ヘッダフィールドを生成する事が *でき*、プロクシやゲートウェイはエンドトゥエンドでの状態チェックとい う価値が失われてしまうので、これを生成し *てはならない*。ゲートウェイ やプロクシを含むあらゆるエンティティボディの受信者は、このヘッダフィ ールド内のダイジェスト値が受信したエンティティボディのものと一致する かどうかをチェックする事が *できる*。 MD5 ダイジェストは、エンティティボディの内容に基づいて計算されるが、 これは適用される内容コーディングは含むが、メッセージボディに適用され る転送コーディングは含めない。メッセージに転送コーディングがなされて いる場合、そのエンコーディングは受け取ったエンティティについての Content-MD5 値をチェックする前に取り除かれ *なければならない*。 これによって、もし転送コーディングが適用されずに送信された場合でも、 ダイジェストを正確にエンティティボディのオクテットに基づいて計算する 事ができる。 HTTP は、MIME 複合メディアタイプのダイジェスト (例えば、multipart/ * や message/rfc822) を計算できるように RFC 1864 を拡張したが、前の段落 で定義したようなダイジェストの計算方法は変わらない。 ここにいくつか重要な点がある。複合型のエンティティボディは、それぞれ が MIME や HTTP ヘッダ (Content-MD5, Content-Transfer-Encoding, Content-Encoding 各ヘッダを含む) を持つような、複数のボディ部分{body- part} を持つ事が *できる*。もしボディ部分に Content-Transfer-Encoding か Content-Encoding のどちらかのヘッダがあれば、そのボディ部分の内容 はエンコーディングが適用されているとみなされ、Content-MD5 ダイジェス トにはそのまま、すなわちエンコーディングが適用された後のボディ部分で ある、とみなされる。Transfer-Encoding ヘッダフィールドは、ボディ部分 に含む事は許されない。 ダイジェストを計算、あるいはチェックする前には、どんな改行も CRLF に 変換し *てはならない*。すなわち、実際に送信されたテキストで使われた改 行規定は、ダイジェストを計算する時までそのままにしておか *なければな らない*。 注意: HTTP における Content-MD5 の定義は、RFC 1864 での MIME エンティ ティボディについてのものと全く同一であるが、HTTP エンティティボディへ の Content-MD5 の適用とMIMEエンティティボディへのものとを区別する方法 がいくつかある。まず一つは HTTP は、MIME とは違い、Content-Transfer- Encoding を使わずに、Transfer-Encoding や Content-Encoding を使う。次 に、HTTP は MIME よりも頻繁にバイナリ内容タイプを使うが、その場合は、 ダイジェストを計算するのに使ったバイトオーダーが、そのタイプで定義さ れた伝送バイトオーダーであるという事に注意する必要がある。最後に、 HTTP では正当な形式である CRLF 以外の改行規定を持つテキストタイプの伝 送を許している。 14.16 Content-Range Content-Range エンティティヘッダフィールドは、共に送られるエンティテ ィボディの一部が、エンティティボディ全体のうちどこに当たるものかを示 すために送られる。レンジ単位は、section 3.12 にて定義されている。 Content-Range = "Content-Range" ":" content-range-spec content-range-spec = byte-content-range-spec byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" ( instance-length | "*" ) byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) | "*" instance-length = 1*DIGIT エンティティボディ全体の長さがわからない、あるいはそれを決定するのが 難しいというので無ければ、このヘッダにはその全体の長さを含む *べきで ある*。アスタリクス "*" という文字があった場合、そのレスポンスが生成 された時点では instance-length はわからないという事を意味する。 byte-ranges-specifier 値 (section 14.35.1 参照) とは違い、byte-range- resp-spec では、範囲は一つのみ、そしてその範囲の最初と最後のバイトを 絶対バイト位置で指定し *なければならない*。 last-byte-pos 値が first-byte-pos 値より小さかったり、instanse-length 値が last-byte-pos 値以下であるような byte-range-resp-spec を持った byte-content-range-spec は不正である。不正な byte-content-range-spec を受信しても、その値、そしてそれと共に送られてきた内容は無視し *なけ ればならない*。 レスポンスと共に 416 (Requested range not satisfiable) というステータ スコードを送るサーバは、byte-range-resp-spec が "*" である Content- Range フィールドを含む *べきである*。instance-length は、選択されたリ ソースの現在の長さを示す。206 (Partial Content) というステータスコー ドのレスポンスには、byte-range-resp-spec が "*" である Content-Range フィールドを含ん *ではならない*。 byte-content-range-spec 値の例として、エンティティが全体で 1234 バイ ト持っていると仮定する。 . 最初の 500 バイト: bytes 0-499/1234 . 次の 500 バイト: bytes 500-999/1234 . 最初の 500 バイト以外すべて: bytes 500-1233/1234 . 最後の 500 バイト: bytes 734-1233/1234 HTTP メッセージが単一のレンジ (例えば、単一のレンジへのリクエスト、あ るいは複数レンジであっても隙間無く重なるようなセットへのリクエスト等 へのレスポンス) の内容を含んでいる場合、この内容は Content-Range ヘッ ダと、実際に転送されるバイト数を示した Content-Length ヘッダを伴う。 例を見よ。 HTTP/1.1 206 Partial content Date: Wed, 15 Nov 1995 06:25:24 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Content-Range: bytes 21010-47021/47022 Content-Length: 26012 Content-Type: image/gif HTTP メッセージが複数のレンジ (例えば、その範囲が重ならないような複数 レンジへのリクエストのレスポンス) の内容を含んでいる場合、それらはマ ルチパートメッセージとして転送される。この目的で使われるマルチパート メディアタイプは、付録 19.2 にて定義される "multipart/byteranges" で ある。互換性の問題に付いては、付録 19.6.3 参照。 単一レンジへのリクエストのレスポンスには、multipart/byteranges メディ アタイプを使って送っ *てはならない*。結果的に単一レンジになるような、 複数レンジへのリクエストのレスポンスには、その部分を送るのに multipart/byteranges メディアタイプを使っても *よい*。 multipart/byteranges メッセージをデコードできないクライアントは、一つ のリクエストで複数のバイトレンジを要求し *てはならない*。 クライアントが１つのリクエストで複数のバイトレンジを要求した時、サー バはリクエストされた順にバイトレンジを返す *べきである*。 サーバがシンタックス上不正だという理由で byte-range-spec を無視した場 合、サーバはその不正な Range ヘッダフィールドが存在しない時と同様にそ のリクエストを扱う *べきである*。 (通常、それはエンティティ全体を含ん だ 200 レスポンスを返す事を意味する。) もし、サーバが満足できない Range リクエストヘッダフィールド (つまり、 その byte-range-spec 値のすべてにおいて、first-byte-pos の値が選択さ れたリソースの現在の長さを越えているようなもの) を含んだ (If-Range リ クエストヘッダフィールドを含む場合以外の) リクエストを受けたならば、 416 (Requested range not satisfiable) というレスポンスコードを返す *べきである* (section 10.4.17)。 注意: すべてのサーバがこのリクエストヘッダを実装しているわけではない ので、クライアントは満足できない Range リクエストヘッダフィールドへの レスポンスとして、サーバが 200 (OK) レスポンスの代わりに 416 (Requested range not satisfiable) レスポンスを送るであろうという事を 当てにはできない。 14.17 Content-Type Content-Type エンティティヘッダフィールドは、受信者に送られるエンティ ティボディのメディアタイプを示し、HEAD メソッドの場合は、GET リクエス トがなされた場合に送られるエンティティボディのメディアタイプを示す。 Content-Type = "Content-Type" ":" media-type メディアタイプは section 3.7 にて定義されている。このフィールドの使用 例を見よ。 Content-Type: text/html; charset=ISO-8859-4 エンティティのメディアタイプを識別するための方法については、section 7.2.1 にて更に詳しく記述されている。 14.18 Date Date 一般ヘッダフィールドは、メッセージが生成された日付・時刻を表し、 RFC 822 の orig-date と同じセマンティクスを持つ。フィールド値は、 section 3.3.1 にて示される HTTP-date であり、RFC 1123 [8] の時刻フォ ーマットが送られ *なければならない*。 Date = "Date" ":" HTTP-date 例を見よ。 Date: Tue, 15 Nov 1994 08:12:31 GMT オリジンサーバは、以下の場合を除き、すべてのレスポンスに Date ヘッダ フィールドを含め *なければならない*。 1. もし、レスポンスステータスコードが 100 (Continue) か 101 (Switching Protocols) ならば、レスポンスはサーバのオプションと して、Date ヘッダフィールドを含める事が *できる*。 2. もし、レスポンスステータスコードが、例えば 500 (Internal Server Error) や 503 (Service Unavailable) 等のサーバエラーを表せば、 有効な Date ヘッダを生成する事は、不便であり不可能である。 3. もし、サーバが有効な現在時刻を表せる時計を持っていなければ、レ スポンスは Date ヘッダフィールドを含め *てはならない*。この場 合、section 14.18.1 にある規則に従わ *なければならない*。 Date ヘッダフィールドを持たないメッセージが、メッセージが受信者によっ てキャッシュされたり、Date ヘッダが要求されるプロトコルによって経由さ れていれば、受信者がそれを割り当て *なければならない*。時計を持たない HTTP インプリメンテーションは、使うたびにその有効性を再検証しない限り はレスポンスをキャッシュし *てはならない*。HTTP キャッシュ、特に共有 キャッシュは、NTP [28] のような、信頼できる外部の標準の時計と同期する ためのメカニズムを使う *べきである*。 クライアントは、PUT リクエストや POST リクエストのように、エンティテ ィボディを含むようなメッセージにのみ Date ヘッダフィールドを送る *べ きである* が、省略してもよい。時計を持たないクライアントは、リクエス トに Date ヘッダフィールドを送っ *てはならない*。 Date ヘッダ中に送られる HTTP-date は、メッセージ生成後の日付・時刻を 表す *べきではない*。もし、インプリメンテーションがかなり正確な日付・ 時刻を生成できるというので無ければ、メッセージの生成時刻として最も利 用可能な近似値を表す *べきである*。理論上は、日付はエンティティを生成 する直前の時刻を表すべきである。しかし実用上は、メッセージの生成中な らば、その意味上の値に影響を及ぼす事無く、いつでも生成できる。 14.18.1 時計の無いサーバの動作 オリジンサーバインプリメンテーションの中には、利用可能な時計を持って いないものがあるかもしれない。時計の無いオリジンサーバは、信頼ある時 計を持つシステムやユーザによるリソースに関連付けられた値で無ければ、 Expires や Last-Modified 値を割り当て *てはならない*。しかし、そのサ ーバが設置される時刻以前の、それが過去であるとわかっている Expires 値 は割り当てる事が *できる* (これは、各々のリソースの Expires 値を分け て保存する事無く、レスポンスの "pre-expiration" を許す) 。 14.19 ETag ETag レスポンスヘッダフィールドは、リクエストされたバリアントのエンテ ィティタグの現在の値を示す。エンティティタグと共に使われるヘッダは、 section 14.24, 14.26, section 14.44 にて記されている。エンティティタ グは、同じリソースからの他のエンティティとの比較に使う事が *できる* (section 13.3.3 参照)。 ETag = "ETag" ":" entity-tag 例を見よ。 ETag: "xyzzy" ETag: W/"xyzzy" ETag: "" 14.20 Expect 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 参照。 14.21 Expires 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) にて何らかの指示がなされていなければ、そのレ スポンスはキャッシュ可能である。 14.22 From もし From リクエストヘッダフィールドが与えられていれば、そこにはリク エストしているユーザエージェントを操っている人間のインターネット e-mail アドレスが含められている *べきである*。そのアドレスは、RFC 1123 [8] によってアップデートされた RFC 822 [9] の中で定義されている ような、マシンが使えるものである *べきである*。 From = "From" ":" mailbox 例を見よ。 From: webmaster@w3.org このヘッダフィールドは、ログを取るという目的や不正なあるいは望まない リクエストの原因を究明するために使う事が *できる*。アクセス保護の安全 性が確保できない形態では使う *べきではない*。このフィールドは、このリ クエストがそのメソッドを実行する責任を持つ者に代わって実行された、と いう事を意味する。特に、ロボットエージェントは、受信後に問題が起きた 場合にロボットを操作している責任者に連絡を取るために、このヘッダを含 める *べきである*。 このフィールドのインターネット e-mail アドレスは、リクエストを発行す るインターネットホストとは異なるものを使う事が *できる*。例えば、リク エストがプロクシを通して送られた場合、元々のリクエスト者のアドレスが 使われる *べきである*。 クライアントは、それがユーザのプライバシーへの関心やそのサイトのセキ ュリティポリシーにそぐわないかもしれないので、From ヘッダフィールドを ユーザの承認無しには送る *べきではない*。ユーザが、リクエストの前にこ のフィールドの値を使用不可にしたり、使用可能にしたり、修正したりでき るようする事を強く推奨する。 14.23 Host 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") を使用する事を意 味する。例えば、 のオリジンサーバへのリク エストは、厳密には以下のものを含んでいるであろう。 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 に関するその他の必要条件については、section 5.2 及び 19.6.1.1 を 見よ。 14.24 If-Match If-Match リクエストヘッダフィールドは、メソッドを条件付きにするために 使われる。以前にそのリソースから一つ以上のエンティティを取得している クライアントは、If-Match ヘッダフィールド中に関連するエンティティタグ のリストを含める事によって、それらのエンティティの一つが現在使用され ているものかどうかを確かめる事ができる。エンティティタグは、section 3.11 にて定義されている。この機能は、トランザクションのオーバーヘッド を最小量にするようにキャッシュされた情報を能率的に更新する事を目的と している。また、間違ったバージョンのリソースを不注意に更新させないた めに、更新リクエストにも使用される。特別な場合として、"*" という値 は、そのリソースの現在のあらゆるエンティティに一致する。 If-Match = "If-Match" ":" ( "*" | 1#entity-tag ) もし、いずれかのエンティティタグがそのリソースへの類似した (If-Match ヘッダが無い) GETリクエストのレスポンスとして返されるであろうエンティ ティのエンティティタグに一致する場合か、"*" が与えられている場合にそ のリソースとして現在使用できるエンティティが存在する場合には、サーバ はそのリクエストに If-Match ヘッダが無い場合と同じようにリクエストさ れた動作を行う事が *できる*。 サーバが If-Match にあるエンティティタグを比較するためには強い比較関 数 (section 13.3.3 参照) を使わ *なければならない*。 エンティティタグに一致するものが無かったり、"*" が与えられていてもそ のリソースとして現在使用できるエンティティが存在しない場合には、サー バはリクエストされた動作を実行し *てはならない* 代わりに、412 (Precondition Failed) レスポンスを返さ *なければならない*。この振る舞 いは、クライアントが、ある時点に取得してから更新されたリソースを、例 えば PUT のような更新メソッドによって、更新されないようにしたい場合に 最も有用である。 If-Match を持たないリクエストが 2xx や 412 以外の結果を返す時は、If- Match ヘッダは無視され *なければならない*。 "If-Match: *" とは、オリジンサーバ (あるいは Vary メカニズムを使う事 ができるようなキャッシュ、section 14.44 参照) によって選択された表現 がある時にはそのメソッドは実行される *べきであり*、その表現が無い時に はそのメソッドは実行され *てはならない* という事を意味する。 リソースを更新しようとするリクエスト (例えば PUT) は、もし If-Match の値 (単一のエンティティタグ) に対応するエンティティが、もはやそのリ ソースの表現で無い場合にはそのリクエストメソッドを適用し *てはならな い* という事を表すために If-Match ヘッダフィールドを含める事が *でき る*。これによってユーザは、リソースが知らないうちに更新されていた場合 にリクエストを成功させないようにしたいという事を示す事ができる。例を 見よ。 If-Match: "xyzzy" If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-Match: * If-Match ヘッダフィールドと同時に If-None-Match か If-Modified-Since ヘッダフィールドを使用しているようなリクエストについては、この仕様書 ではその結果についてを定義しない。 14.25 If-Modified-Since 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 If-Modified-Since ヘッダを持っていて且つ Range ヘッダを持たない GET メソッドは、If-Modified-Since ヘッダによって与えられる時刻以降に更新 された場合のみ指定したエンティティを転送する事を要求する。これを決定 するためのアルゴリズムには、以下のようなものを含む。 a) リクエストが 200 (OK) ステータス以外の結果を返すか、あるいは渡 された If-Modified-Since の日付が不正なものであるような場合、レ スポンスは通常の GET 時と全く同じものとなる。サーバの現在時刻よ り未来の時刻は無効である。 b) バリアントが If-Modified-Since にある時刻以降に更新されている場 合、レスポンスは通常の GET 時と全く同じものとなる。 c) バリアントが有効な If-Modified-Since にある時刻以降に更新されて いない場合、サーバは 304 (not modified) レスポンスを返す *べき である*。 この機能は、トランザクションのオーバーヘッドを最小量にするようにキャ ッシュされた情報を能率的に更新する事を目的にしている。 注意: Range リクエストヘッダフィールドは、If-Modified-Since の意味を 変更する。詳細については section 14.35 参照。 注意: If-Modified-Since の時刻はサーバによって解釈されるが、この時計 はクライアントのものとは同期していないかもしれない。 注意: If-Modified-Since ヘッダフィールドを扱う時、いくつかのサーバは 304 (not modified) レスポンスを返すかどうかを決定する際に、それ以下で あるかを見る関数{less-than function} よりも、正確に時刻を比較する関数 {comparison function} を使うであろう。キャッシュの妥当性{validation} のために If-Modified-Since ヘッダフィールドを送った時に最良な結果を得 るためには、クライアントは可能であればいつでも直前の Last-Modified ヘ ッダフィールドにて受けたそのままの時刻文字列を使う事を提案する。 注意: クライアントが同じリクエストから取得した Last-Modified ヘッダか ら得られた時刻の代わりに If-Modified-Since ヘッダに任意の時刻を使った としたら、クライアントはこの日付がサーバが決めている時刻の取り決めに 従って解釈されるという事に注意すべきである。クライアントは、クライア ントとサーバ間の時計のズレや異なるエンコーディングの使用による丸めの 問題を考慮するべきである。これは、もし最初にリクエストした時刻からそ の後の If-Modified-Since にある時刻までに文書が変化した場合に競合状態 が起こる可能性や、If-Modified-Since の日付がサーバの時計による修正無 しにクライアントの時計から導出された場合に {clock-skew-related} 問題 がおこる可能性を示している。クライアントとサーバ間の時計のズレの修正 は、ネットワーク間での待ち時間があるので、全く同じにする事はできな い。 If-Modified-Since ヘッダフィールドと同時に If-Match か If-Unmodified- Since ヘッダフィールドを使用しているようなリクエストについては、この 仕様書ではその結果についてを定義しない。 14.26 If-None-Match If-None-Match リクエストヘッダフィールドは、メソッドを条件付きにする 場合に使われる。以前にそのリソースから一つ以上のエンティティを取得し ているクライアントは、If-None-Match ヘッダフィールド中にそれに対応す るエンティティタグのリストを含める事によって、それらのエンティティの 中に現在使用できるものがないかどうかを確かめる事ができる。この機能 は、トランザクションのオーバーヘッドを最小量にするようにキャッシュさ れた情報を能率的に更新する事を目的にしている。また (例えば PUT 等の) メソッドを使う場合に、既にあるリソースをクライアントがそのリソースが 無いと考えている場合に不注意に更新してしまわないようにするためにも使 われる。 特別な場合として、"*" という値は、そのリソースの現在のあらゆるエンテ ィティに一致する。 If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag ) いずれかのエンティティタグがそのリソースにされる類似した (If-None- Match ヘッダが無い) GET リクエストのレスポンスとして返されるエンティ ティのエンティティタグに一致する場合か、"*" が与えられる場合にそのリ ソースに現在使用できるエンティティが存在する場合において、サーバはリ ソースの更新時刻とリクエストの中の If-Modified-Since ヘッダフィールド にて与えられた時刻が一致しなかった場合以外は、リクエストされた動作を 行っ *てはならない*。その代わり、もしリクエストメソッドが GET か HEAD であれば、サーバは 304 (Not Modified) レスポンスを、一致したエンティ ティのうちの一つのキャッシュに関連するヘッダフィールド (特に ETag) を 付けて返す *べきである*。その他のメソッドの場合はすべて、サーバは 412 (Precondition Failed) というステータスを返さ *なければならない*。 二つのエンティティタグが一致しているかどうかを決定する方法についての 決まりについては、section 13.3.3 参照。GET や HEAD リクエストの場合に は、弱い比較関数のみを使う事ができる。 エンティティタグが一致するものが無ければ、サーバはそのリクエストに If-None-Match ヘッダが無い場合と同じようにリクエストされた動作を行う 事が *できる* が、同時にリクエスト中のすべての If-Modified-Since ヘッ ダフィールドは無視され *なければならない*。すなわち、エンティティタグ が一致するものが無ければ、サーバは 304 (Not Modified) レスポンスを返 し *てはならない*。 もし If-None-Match を持たないリクエストが、2xx や 304 各ステータス以 外の結果を返すならば、If-None-Match ヘッダは無視され *なければならな い*。 (あるリクエスト中に If-Modified-Since と If-None-Match が同時に 存在する場合のサーバの振る舞いについての議論は section 13.3.4 を見 よ。) "If-None-Match: *" とは、オリジンサーバ (あるいは Vary メカニズムを使 う事ができるようなキャッシュ、section 14.44 参照) によって選択された 表現がある時には、そのメソッドは実行し *てはならない* が、その表現が 無い時には、そのメソッドは実行する *べきである* という事を意味する。 この機能は、ある二つの PUT 作業中に競合が起こらないようにする場合に有 に有用である。 例を見よ。 If-None-Match: "xyzzy" If-None-Match: W/"xyzzy" If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" If-None-Match: * If-None-Match ヘッダフィールドと同時に If-Match か If-Unmodified- Since ヘッダフィールドを使用しているようなリクエストについては、この 仕様書ではその結果についてを定義しない。 14.27 If-Range もしクライアントがキャッシュとしてあるエンティティのコピーの一部を保 持していて、そのエンティティ全体の最新のコピーが欲しい場合、 (If- Unmodified-Since か If-Match、あるいは両方を使った) 条件付き GET とし て Range リクエストヘッダを使う事ができる。しかし、もしエンティティが 更新されたために条件が成立しなければ、クライアントは最新のエンティテ ィボディ全体を取得するために次なるリクエストをしなければならない。 If-Range ヘッダは、クライアントの次なるリクエストを "短略化{short- circuit}" する事ができる。一般的に、これは「もしエンティティが更新さ れていなかったら、私が持っていない部分を送信してくれ。そうでなけれ ば、新しいエンティティ全体を送信してくれ。」のように解釈される。 If-Range = "If-Range" ":" ( entity-tag | HTTP-date ) クライアントがそのエンティティのエンティティタグは持っていないが、 Last-Modified の日付を持っている場合、クライアントは If-Range ヘッダ としてその日付を使う事が *できる*。 (サーバは、多くても 2 文字を調べ るだけで、正確な HTTP 日付と任意の形式のエンティティタグとを区別する 事ができる。) If-Range ヘッダは Range ヘッダと共にのみ使う *べきであ り*、リクエストが Range ヘッダを含んでいない場合や、サーバが sub- range 操作をサポートしない場合には、これは無視され *なければならな い*。 If-Range ヘッダにて与えられたエンティティタグがそのエンティティの現在 のエンティティタグに一致した場合、サーバは 206 (Partial content) レス ポンスを使って、そのエンティティの指定される sub-range を供給す *べき である*。もしエンティティタグが一致しなければ、サーバは 200 (OK) レス ポンスを使って、そのエンティティ全体を返す *べきである*。 14.28 If-Unmodified-Since 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 通常のリクエスト (すなわち If-Unmodified-Since が無いリクエスト) が、 2xx や 412 以外の結果を返す場合、If-Unmodified-Since ヘッダは無視す *べきである*。 指定された時刻が不正であれば、このヘッダは無視される。 If-Unmodified-Since ヘッダフィールドと同時に If-None-Match か If- Modified-Since ヘッダフィールドを使用しているようなリクエストについて は、この仕様書ではその結果についてを定義しない。 14.29 Last-Modified 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 を送る *べきで ある*。 14.30 Location Location レスポンスヘッダフィールドは、リクエストを完了するため、ある いは新しいリソースを識別するため、受信者を Request-URI 以外の場所にリ ダイレクトするのに使われる。201 (Created) レスポンスの場合、Location はリクエストによって作られた新しいリソースの場所である。3xx レスポン スの場合、Location はリソースへ自動でリダイレクションさせるためにサー バが望む URI を示す *べきである*。このフィールド値は、単一の絶対 URI から成る。 Location = "Location" ":" absoluteURI 例を見よ。 Location: http://www.w3.org/pub/WWW/People.html 注意: Content-Location ヘッダフィールド (section 14.14) は、リクエ ストと共に送られるエンティティのオリジナルの場所を指すという点で、 Location ヘッダとは異なる。それ故に、レスポンスは Location と Content-Location の両ヘッダフィールドを含む事は可能である。いくつ つかのメソッドでのキャッシュの必要条件については、section 13.10 も 合わせて見よ。 14.31 Max-Forwards Max-Forwards リクエストヘッダフィールドは、TRACE (section 9.8) や OPTIONS (section 9.2) の各メソッドに、次のインバウンドサーバにリクエ ストを転送できるプロクシやゲートウェイの数を制限するというメカニズム を提供する。これは、クライアントが、その中間で失敗したりループしたり しているリクエスト連鎖を追跡しようとする場合に有用である。 Max-Forwards = "Max-Forwards" ":" 1*DIGIT Max-Forwards 値は、このリクエストメッセージが残り何回転送できるかとい う回数を表す 10 進数の整数値である。 Max-Forwards ヘッダフィールドを含む TRACE あるいは OPTION リクエスト を受けたプロクシやゲートウェイは、リクエストを転送する前にその値を調 べ、更新し *なければならない*。もし、受けとった Max-Forwards の値が 0 であれば、受信者はそのリクエストを転送し *てはならない* 代わりに、最 後の受信者として応答し *なければならない*。受けとった Max-Forwards の 値が 0 以上であれば、転送されるメッセージにはその値から 1 を引いた値 に更新した Max-Forwards フィールドを含め *なければならない*。 Max-Forwards ヘッダフィールドは、その仕様書で定義された他のすべてのメ ソッドや、そのメソッド定義の部分で明確に述べられていない拡張メソッド 中では無視しても *よい*。 14.32 Pragma 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" の確実な代用とはならない。 14.33 Proxy-Authenticate Proxy-Authenticate レスポンスヘッダフィールドは、407 (Proxy Authentication Required) レスポンスの一部として含め *なければならな い*。このフィールド値は、この Request-URI のプロクシに適用される認証 スキームとパラメータを含む challenge から成る。 Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge HTTP アクセス認証処理方法については、"HTTP Authentication: Basic and Digest Access Authentication" [43] にて記述されている。WWW- Authenticate とは違い、Proxy-Authenticate ヘッダフィールドは現在の接 続にのみ適用され、またダウンストリームのクライアントに通す *べきでは ない*。しかし、中間のプロクシがダウンストリームのクライアントからリク エストされる事によって自身の credentials を得る必要がある可能性があ り、そのような場合はまるでプロクシが Proxy-Authenticate ヘッダフィー ルドを転送しているように見える事がある。 14.34 Proxy-Authorization Proxy-Authorization リクエストヘッダフィールドを使って、クライアント は認証を要求するプロクシに自身 (やそのユーザ) を識別させる。Proxy- Authorization のフィールド値は、プロクシやリクエストされたリソースの ある領域へのユーザエージェントの認証情報を含む credentials から成る。 Proxy-Authorization = "Proxy-Authorization" ":" credentials HTTP アクセス認証処理方法については、"HTTP Authentication: Basic and Digest Access Authentication" [43] にて記述されている。Authorization とは違い、Proxy-Authorization ヘッダフィールドは Proxy-Authorization を使って認証を要求する次のアウトバウンドプロクシにのみ適用される。連 鎖内に複数のプロクシがある時は、Proxy-Authorization ヘッダフィールド は、credentials を受け取ろうとしている最初のアウトバウンドプロクシに よって消去される。もしプロクシが与えられたリクエストを協同で認証する ようなメカニズムならば、プロクシはリクエストから次のプロクシへとクラ イアントの credentials を取り次ぐ事が *できる*。 14.35 Range 14.35.1 バイトレンジ HTTP メッセージ中では、すべての HTTP エンティティがバイトシーケンスで 表せるので、バイトレンジの概念はあらゆる HTTP エンティティにとって意 義のあるものである。 (しかしながら、すべてのクライアントとサーバがバ イトレンジ操作をサポートする必要は無い。) HTTP でのバイトレンジ指定は、エンティティボディ (それがメッセージボデ ィと同一で無くてもよい) 中のバイトシーケンスに適用される。 バイトレンジ操作では、単一のバイトレンジ、または一つのエンティティ中 で複数のレンジセットを指定する事が *できる*。 ranges-specifier = byte-ranges-specifier byte-ranges-specifier = bytes-unit "=" byte-range-set byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec ) byte-range-spec = first-byte-pos "-" [last-byte-pos] first-byte-pos = 1*DIGIT last-byte-pos = 1*DIGIT byte-range-spec 中の first-byte-pos 値には、その範囲の最初のバイトの byte-offset を与える。last-byte-pos 値には、その範囲の最後のバイトの byte-offset を与える。つまり、指定されるバイトの位置も含まれる。バイ トオフセットは 0 から始まる。 last-byte-pos 値がある場合、その値は byte-range-spec での first-byte- pos 以上のものにし *なければならない* が、そうで無い場合はシンタック ス上不正となる。一つ以上のシンタックス上不正な byte-range-spec 値を含 む byte-range-set を受信しても、その byte-range-set を含むヘッダフィ ールドは無視し *なければならない*。 last-byte-pos 値が無い、あるいはその値が現在のエンティティボディの大 きさ以上であったら、last-byte-pos はエンティティボディの現在のバイト 長から 1 を引いた値になる。 クライアントは、自身が指定する last-byte-pos によって、エンティティの サイズを知らなくても受け取るバイト数を制限する事ができる。 suffix-byte-range-spec = "-" suffix-length suffix-length = 1*DIGIT suffix-byte-range-spec は、エンティティボディの、suffix-length 値によ って与えられる長さの末尾を指定するのに使われる。 (すなわち、この形式 ではエンティティボディの最後の N バイトを指定する。) もしエンティティ が指定された suffix-length 以下の長さしかなければ、エンティティ全体が 使われる。 シンタックス上不正な byte-range-set が、first-byte-pos が現在のエンテ ィティボディ長よりも小さいような byte-range-spec、あるいは 0 でない suffix-length を持つ suffix-byte-range-spec を一つでも含んでいたら、 その byte-range-set はシンタックスを満足する。そうでない byte-range- set は不正値である。byte-range-set が不正値である場合、サーバは 416 (Requested range not satisfiable) というステータスを持ったレスポンス を返す *べきである*。そうで無ければ、サーバはエンティティボディのうち 指定された範囲と 206 (Partial Content) というステータスを持ったレスポ ンスを返す *べきである*。 byte-ranges-specifier 値の例を示す (エンティティボディの大きさを 10000 と仮定する)。 - 最初の 500 バイト (バイトオフセットは始点・終点を含めて、0-499) : bytes=0-499 - 次の 500 バイト (バイトオフセットは始点・終点を含めて、500-999) : bytes=500-999 - 最後の 500 バイト (バイトオフセットは始点・終点を含めて、9500- 9999) : bytes=-500 - あるいは bytes=9500- - 最初と最後の 1 バイト (バイトオフセットは 0 と 9999) : bytes=0-0,-1 - 間違いではないが一般的ではない次の 500 バイトの指定方法 (バイト オフセットは始点・終点を含めて、500-999) : bytes=500-600,601-999 bytes=500-700,601-999 14.35.2 レンジ更新リクエスト 条件付き、あるいは条件の付かない GET メソッドを使った HTTP 検索リクエ ストは Range リクエストヘッダを使って、エンティティ全体の代わりに、エ ンティティの一つ以上の sub-range を要求 *でき*、リクエストの結果とし て返されるエンティティに当たる。 Range = "Range" ":" ranges-specifier サーバは、Range ヘッダを無視 *できる*。しかし、Range をサポートするこ とで転送に失敗した部分の再取得や、大きなサイズのエンティティの部分的 な検索を効果的にサポートするので、HTTP/1.1 のオリジンサーバや中間キャ ッシュは、可能であればバイトレンジをサポートすべきである。 もし、サーバが Range ヘッダをサポートし、指定される範囲 (群) がそのエ ンティティに適切であれば、以下の様になる。 - 条件の付かない GET に Range ヘッダがあった場合、その GET が他の 点で成功していれば、返る値が修正される。言いかえると、レスポンス は 200 (OK) の代わりに 206 (Partial Content) というステータスコ ードを返す。 - 条件付きの GET (If-Modified-Since と If-None-Match のどちらかあ るいは両方、もしくは If-Unmodified-Since と If-Match のどちらか あるいは両方を使ったリクエスト) に Range ヘッダがあった場合、そ の GET が他の点で成功していて、条件が真であったら、返る値が修正 される。もし条件が偽であれば、304 (Not Modified) レスポンスには 影響ない。 場合によっては、Range ヘッダに加えて If-Range ヘッダ (section 14.27 参照) を使う方が適切であるかもしれない。 もし、レンジをサポートするプロクシが Range リクエストを受け、そのリク エストをインバウンドサーバに転送し、その返答としてエンティティ全体を 受け取ったとしたら、プロクシはクライアントが要求した範囲のみを返す *べきである*。もしそれがキャッシュの割り当て方針にあったものであれ ば、キャッシュには受け取ったレスポンス全体を保存す *べきである*。 14.36 Referer Referer[原文ママ] リクエストヘッダフィールド ("referrer" であるはずな のに綴りは間違っているが) は、サーバの利益のために、Request-URI が得 られたリソースのアドレス (URI) をクライアントに示させる。Referer リク エストヘッダは、サーバが興味やログの取得、キャッシュの活用等のため に、そのリソースへの逆リンクのリストを作成できるようにする。また、メ ンテナンスのために、既に使用していない{obsolete} リンクやミスタイプの リンクを追跡できるようにもする。もし Request-URI が、例えばユーザのキ ーボードからの入力など、それ自身の URI を持たないソースから得られた場 合は、Refererフィールドを送っ *てはならない*。 Referer = "Referer" ":" ( absoluteURI | relativeURI ) 例を示す。 Referer: http://www.w3.org/hypertext/DataSources/Overview.html もしこのフィールド値が相対 URI ならば、Request-URI からの相対的なもの と解釈す *べきである*。URI にはフラグメントを含め *てはならない*。セ キュリティ上の考察については、section 15.1.3 参照。 14.37 Retry-After 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分である。 14.38 Server Server レスポンスヘッダフィールドは、リクエストを処理するオリジンサー バが使っているソフトウェアについての情報を含んでいる。このフィールド には、複数の製品トークン (section 3.8) や、サーバとその他の重要な付属 製品を識別するためのコメントを含める事ができる。製品トークンは、アプ リケーションを識別するために重要な順に列挙される。 Server = "Server" ":" 1*( product | comment ) 例を見よ。 Server: CERN/3.0 libwww/2.17 レスポンスがプロクシを通して送られた場合、プロクシアプリケーションは Server レスポンスヘッダを書き換え *てはならない*。代わりに、 (section 14.45 に記述されている) Via フィールドを使う *べきである*。 注意: サーバのソフトウェアバージョンを明らかにする事で、セキュリテ ィホールを持っている事がわかっているソフトウェアを使うサーバのマシ ンは攻撃を受けやすくなるかもしれない。サーバの開発者は、このフィー ルドをオプションとして設定を変更できるようにする事が推奨される。 14.39 TE TE リクエストヘッダフィールドは、レスポンスとしてどんな拡張転送コーデ ィングを受け入れられるか、またチャンク形式転送コーディング内の trailer フィールドを受け入れられるかどうかを示す。この値は、 "trailers" というキーワードや、 (section 3.6 にて定義される) 拡張転送 コーディングの名前と省略可能な受け入れパラメータをコンマで区切ったリ ストからなるだろう。 TE = "TE" ":" #( t-codings ) t-codings = "trailers" | ( transfer-extension [ accept-params ] ) "trailers" というキーワードがあれば、section 3.6.1 にて定義されるよう に、クライアントはチャンク形式転送コーディング内の trailer フィールド を受け入れられる、という事を表す。このキーワードは、たとえクライアン トが転送コーディングを表せないとしても、転送コーディング値を使うため に予約される。 その使用例は以下のようになる。 TE: deflate TE: TE: trailers, deflate;q=0.5 TE ヘッダフィールドは、直接の接続にのみ適用される。それゆえ、TE が HTTP/1.1 メッセージに存在する時は常に、このキーワードを Connection ヘ ッダフィールド (section 14.10) の中に与え *なければならない*。 サーバは、TE フィールドによって与えられた転送コーディングが受け入れ可 能かを試すために、以下の規則を使う事ができる。 1. "chunked" 転送コーディングは常に受け入れ可能である。"trailers" というキーワードが列挙されていれば、クライアントは、自身やダウ ンストリームのクライアントがチャンク形式のレスポンス中の trailer フィールドを受け入れ可能である、という事を示す。このフ ィールドが与えられた場合、クライアントは、すべてのダウンストリ ームクライアントは転送されるレスポンス中の trailer フィールドを 受け入れ可能であるか、あるいはダウンストリームの受信者のために レスポンスをバッファしようとしているか、のどちらかを示している 事を意味する。 注意: HTTP/1.1 は、クライアントがレスポンス全体のバッファリング を保証できるようなチャンク形式レスポンスのサイズの制限するため の手段を定義しない。 2. 現在試している転送コーディングが TE フィールド内に列挙されてい る転送コーディングの一つで、その qvalue が 0 でなければ、受け入 れ可能である。 (section 3.9 にて定義されるように、qvalue が 0 であるという事は、"受け入れ不可能" を意味する。) 3. 複数の転送コーディングが受け入れ可能である時は、qvalue が 0 以 上で最も大きい値を持つ転送コーディングが優先される。"chunked" 転送コーディングの qvalue は常に 1 である。 TE フィールド値が空か、あるいは TE フィールドが与えられていなければ、 使用できる転送コーディングは "chunked" のみとなる。転送コーディングが なされていないメッセージは、常に受け入れ可能である。 14.40 Trailer Trailer 一般フィールドの値は、その中で与えられたヘッダフィールドのセ ットがチャンク形式転送コーディングにてエンコードされたメッセージの後 につけられるもの{trailer} の中に含まれている事を表す。 Trailer = "Trailer" ":" 1#field-name HTTP/1.1 のメッセージは、チャンク形式転送コーディングされ空ではない trailer を持っているメッセージ中では Trailer ヘッダフィールドを含む *べきである*。そうする事で、受信者は trailer の中にどんなヘッダフィー ルドがあるかを知る事ができる。 Trailer ヘッダフィールドがなければ、trailer はいかなるヘッダフィール ドも含む *べきではない*。"chunked" 転送コーディング中の trailer フィ ールドの使用の制限については、section 3.6.1 参照。 Trailer ヘッダフィールド中に列挙されるメッセージヘッダフィールドには 以下のヘッダフィールドを含め *てはならない*。 . Transfer-Encoding . Content-Length . Trailer 14.41 Transfer-Encoding Tranfer-Encoding 一般ヘッダフィールドは、 (もし変形がなされていれば) 送信者と受信者の間でメッセージボディを安全に転送するために、適用され ている変形の形を示す。転送コーディングというのは、メッセージの特性で あり、エンティティの特性では無い、という点で内容コーディングとは異な る。 Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding 転送コーディングは section 3.6 にて定義される。例を見よ。 Transfer-Encoding: chunked もしエンティティに複数のエンコーディングが適用されていたら、適用され ている順番に列挙し *なければならない*。エンコーディングパラメータにつ いての追加的情報は、この仕様書に定義されていない他のエンティティヘッ ダフィールドによって与える事が *できる*。 多くの古い HTTP/1.0 アプリケーションは、Transfer-Encoding ヘッダを理 解しない。 14.42 Upgrade 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 からある他の、互換性が無いプロト コルへの変換のための単純なメカニズムを提供する事を目的としている。こ れは、クライアントがたとえ現在のリクエストが HTTP/1.1 を使って作られ たものであっても、例えばより大きなメジャーバージョン番号を持つ新しい バージョンの HTTP のような、他のプロトコルを使いたいという要求をした 場合に変換が行われる。これは、クライアントがもしそれが利用できれば "よりよい" プロトコルを使用したいという事をサーバに示している間に、よ り一般的にサポートされるプロトコルでリクエストを開始させる事で、互換 性の無い互いのプロトコル間の難しい変換を簡単にする (ここでの "よりよ い" とは、リクエストされているメソッドやリソースの性質に応じて、サー バが決定する)。 Upgrade ヘッダフィールドは、現在のトランスポート層にある接続上のアプ リケーション層プロトコルの切り替えにのみ適用される。Upgrade は、プロ トコルの変換を強要する事はできない。すなわち、サーバがこのフィールド を受け入れるか、それをどう使うかはサーバによる。プロトコル変換後の最 初の動作は Upgrade ヘッダフィールドを含む最初の HTTP リクエストへのレ スポンスで *なければならない* が、プロトコルの変換後のアプリケーショ ン層の通信能力とその性質は完全に選択された新しいプロトコルに依存す る。 Upgrade ヘッダフィールドは、直接の接続にのみ適用される。それゆえ、 Upgrade が HTTP/1.1 メッセージに存在する時は常に、upgrade というキー ワードを Connection ヘッダフィールド (section 14.10) の中に与え *なけ ればならない*。 Upgrade ヘッダフィールドは、異なる接続でプロトコルを変換するために使 う事はできない。この場合、301, 302, 303, 305 のいずれかのリダイレクシ ョンレスポンスを使う方が適切である。 この仕様書では、section 3.1 の HTTP バーションの規則と将来更新される この仕様書に定義されるように、ハイパーテキスト転送プロトコルのファミ リーとして使用するための "HTTP" というプロトコル名のみを定義する。プ ロトコル名としてはあらゆるトークンが使用できるが、クライアントとサー バの両方がその名前で同じプロトコルを関連付けている場合のみそれが有効 となるであろう。 14.43 User-Agent User-Agent リクエストヘッダフィールドは、リクエストを生成したユーザエ ージェントについての情報を含む。これは、統計目的、プロトコル違反の追 跡、特定のユーザエージェントの制限を回避するようなレスポンスを作成す るためのユーザエージェントの自動認識のために使う。ユーザエージェント は、リクエストの際にこのヘッダを含む *べきである*。このフィールドに は、複数の製品トークン (section 3.8) や、エージェントやユーザエージェ ントの重要な付属製品を識別するためのコメントを含める事ができる。慣習 によれば、製品トークンはアプリケーションを識別するために重要な順に列 挙される。 User-Agent = "User-Agent" ":" 1*( product | comment ) 例を見よ。 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 14.44 Vary Vary フィールド値は、そのレスポンスが新鮮である{fresh} 間、キャッシュ が再検証無しにそれに続くリクエストに対するレスポンスとして使ってよい かどうかを、完全に決定するためのリクエストヘッダフィールドのセットを 示す。キャッシュできない、あるいは新鮮でなくなった{stale} レスポンス の場合、Vary フィールド値はユーザエージェントにその表現を選択するた めに使われた基準{criteria} について通知するために使われる。"*" という Vary フィールド値は、キャッシュはこのレスポンスが適切な表現であるかど うかをそれに続くのリクエストのリクエストヘッダからは決定できない、と いう事を意味する。キャッシュにおける Vary ヘッダフィールドの使い方に ついては section 13.6 参照。 Vary = "Vary" ":" ( "*" | 1#field-name ) HTTP/1.1 サーバは、サーバ駆動型ネゴシエーションを受けるあらゆるキャッ シュ可能なレスポンスに Vary ヘッダフィールド値を含む *べきである*。そ うする事で、キャッシュはそのリソースへの将来のリクエストを適切に解釈 する事ができ、ユーザエージェントにそのリソースへのネゴシエーションの 存在について知らせる事ができる。サーバは、サーバ駆動型ネゴシエーショ ンを受けるキャッシュ不可能なレスポンスにも、ユーザエージェントにその レスポンス時には変化してしまうレスポンスの規模{dimensions} についての 有益な情報を提供するであろうから、Vary ヘッダフィールド値を含む事が *できる*。 Vary フィールド値は、最もふさわしい表現を選択するために列挙されたリク エストヘッダフィールド値 *のみ* を考慮する選択アルゴリズムに従ってレ スポンスとして選択された表現を知らせる field-name の列挙から成る。キ ャッシュは、そのレスポンスが新鮮である間は、列挙されるフィールド名に 同じフィールド値を取るような将来のリクエストでも同じ選択がなされるで あろう、と仮定する事が *できる*。 与えられる field-name は、この仕様書にて定義されている標準のリクエス トヘッダフィールドに制限されない。フィールド名は、大文字・小文字を区 別しない。 "*" という Vary フィールド値は、指定されていないパラメータはリクエス トヘッダに制限されないという事を示し (例えば、クライアントのネットワ ークアドレス) 、レスポンスの表現の選択において役割を果たす。プロクシ サーバは、"*" という値を生成し *てはならない*。それは生成できるのはオ リジンサーバのみである。 14.45 Via Via 一般ヘッダフィールドは、リクエスト時におけるユーザエージェントか らサーバ間の、またレスポンス時におけるオリジンサーバからユーザエージ ェント間の、中間のプロトコルと受信者を示すためにゲートウェイやプロク シによって使われ *なければならない*。これは、RFC 822 [9] での "Received" フィールドに類似しており、転送されるメッセージを追跡した り、リクエストループを回避したり、リクエスト／レスポンス連鎖上のすべ ての送信者のプロトコル能力を識別したりする意図を持つ。 Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) received-protocol = [ protocol-name "/" ] protocol-version protocol-name = token protocol-version = token received-by = ( host [ ":" port ] ) | pseudonym pseudonym = token received-protocol は、リクエスト／レスポンス連鎖上の各セグメントでサ ーバやクライアントから受けたメッセージのプロトコルバージョンを表す。 received-protocol のバージョンは、アップストリームのアプリケーション のプロトコル能力についての情報がすべての受信者に見えるようにするため に、メッセージの転送時に Via フィールドに添えられる。 protocol-name は、"HTTP" である場合のみ省略可能となる。received-by フ ィールドは通常、その後メッセージを転送した受信サーバやクライアントの ホストと省略可能なポート番号である。しかし、本当のホスト名が取り扱い に慎重を要する情報であるとみなされるのであれば、偽名に置き換える事が *できる*。ポート名が与えられなければ、received-protocol のデフォルト ポートであるとみなして *よい*。 複数の Via フィールド値は、それぞれがメッセージを転送したプロクシやゲ ートウェイを表す。それぞれの受信者は、その結果がアプリケーションを転 送する順序になるように末尾に自身の情報を付加し *なければならない*。 コメントは、User-Agent や Server 各ヘッダフィールドと同様に、受信プロ クシやゲートウェイソフトウェアを識別するために Via ヘッダフィールド内 で使う事が *できる*。しかし、Via フィールド内のすべてのコメントは省略 可能であり、他の受信者はそのメッセージを転送する前にそれを削除する事 が *できる*。 例えば、リクエストメッセージが HTTP/1.0 ユーザエージェントから "fred" というコードネームの内部プロクシに送られ、これが HTTP/1.1 を使って nowhere.com にある公衆プロクシにリクエストを転送し、最後に www.ics.uci.edu というオリジンサーバにリクエストを転送する事で完了す る場合を考える。www.ics.uci.edu が受けるリクエストは、次のような Via ヘッダフィールドを持っているだろう。 Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) ネットワークファイアウォールへの入り口として使われるプロクシやゲート ウェイは、デフォルトでは、ファイアウォール域内部のホスト名やポート番 号を転送す *べきではない*。この情報は、明示的に許可された場合にのみ伝 えられる *べきである*。許可されなければ、ファイアウォール内のあらゆる ホストの received-by は、適当な偽名に置き換えられる *べきである*。 内部構造の守秘に関して強いプライバシー要求を持つ組織では、プロクシは 同一の received-protocol 値を持つ連続した Via ヘッダフィールドエント リを一つのエントリに連結する事が *できる*。次の例を見よ。 Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy これは次のようにまとめられる。 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy アプリケーションは、それらがすべて同じ組織コントロール化にあって、ホ スト名が既に偽名に置き換えられている場合以外には、複数のエントリを連 結す *べきではない*。アプリケーションは、異なる received-protocol 値 を持つエントリを連結し *てはならない*。 14.46 Warning Warning 一般ヘッダフィールドは、そのメッセージ中には反映されないであ ろうステータスやメッセージの変化についての付加的情報を伝えるために使 われる。この情報は、キャッシュの処理やメッセージのエンティティボディ に適用される変化から意味的透過性が欠けている可能性がある事を警告する ために定型的に使われる。 Warning ヘッダは、以下のような形式を使ってレスポンスと共に送られる。 Warning = "Warning" ":" 1#warning-value warning-value = warn-code SP warn-agent SP warn-text [SP warn-date] warn-code = 3DIGIT warn-agent = ( host [ ":" port ] ) | pseudonym ; the name or pseudonym of the server adding ; the Warning header, for use in debugging warn-text = quoted-string warn-date = <"> HTTP-date <"> レスポンスでは、複数の Warning ヘッダを転送する事が *できる*。 warn-text は、レスポンスを受けとる人間ユーザが最も理解できそうな自然 言語と文字セットである *べきである*。これはあらゆる利用できる情報、例 えばキャッシュやユーザの場所、リクエスト中の Accept-Language フィール ド、レスポンス中の Content-Language フィールド等に基づいて決定するこ とが *できる*。デフォルトの言語は英語であり、文字セットは ISO-8859-1 である。 ISO-8859-1 以外の文字セットが使われる場合は、RFC 2047 [14] にて記述さ れる方法を用いて warn-text 内でエンコードし *なければならない*。 Warning ヘッダは一般にどんなメッセージにも適用する事ができるが、中に は特定のキャッシュについて言及している warn-code もあり、それについて はレスポンスメッセージにのみ適用できる。新しい Warning ヘッダは、既存 の Warning ヘッダの後に追加される *べきである*。キャッシュは、メッセ ージと共に受け取ったどんな Warning ヘッダも消去し *てはならない*。し かし、キャッシュがキャッシュエントリの検証に成功した場合、特定の Warning コードに指定されているもので無ければ、前もってエントリに付加 されていた Warning ヘッダを消去す *べきである*。そして、そこに検証し た時のレスポンスで受け取ったあらゆる Warning ヘッダを付け加え *なけれ ばならない*。言い換えれば、Warning ヘッダは最新の適切なレスポンスに加 えられるものなのである。 レスポンスに複数の Warning ヘッダが付加されている時は、ユーザエージェ ントは、レスポンス中に現れた順序に従って、できるだけたくさんユーザに 表示すべきである。すべての警告を表示できない場合、ユーザエージェント は以下の規則に従う *べきである*。 - レスポンス中に先に現れた Warning は、後に現れたものよりも優先さ れる。 - ユーザが指定した文字セットの Warning は、同一の warn-code や warn-agent で無ければ他の文字セットのものよりも優先される。 複数の Warning ヘッダを生成するシステムでは、このユーザエージェントの 振る舞いに気をつけて、ヘッダを並べる *べきである*。 Warning を尊重するキャッシュの振る舞いの必要条件は、section 13.1.2 に て述べられている。 以下は、現在定義されている warn-code の一覧と、それぞれに英語での推奨 される warn-text をつけて、その意味について記述したものである。 110 Response is stale 返されるレスポンスが新鮮で無い場合は常にこれを含ま *なければならな い*。 111 Revalidation failed キャッシュがサーバに到達できないという理由で、レスポンスの再検証に 失敗して古いレスポンスを返すという場合はこれを含ま *なければならな い*。 112 Disconnected operation キャッシュが一定の期間にネットワークから故意に切断される場合はこれ を含む *べきである*。 113 Heuristic expiration キャッシュが有効期限を 24 時間以上に設定している時にそのレスポンス の経過時間が 24 時間以上である場合はこれを含ま *なければならない*。 199 Miscellaneous warning この警告文には、それを人間ユーザに表示、記録させるために独自の情報 を含む事が *できる*。この警告を受けたシステムは、警告をユーザに表示 する以外には、どんな自動的なアクションも起こし *てはならない*。 214 Transformation applied (Content-Encoding ヘッダにて指定されるような) 内容コーディング、レ スポンスの (Content-Type ヘッダにて指定されるような) メディアタイ プ、あるいはレスポンスのエンティティボディになんらかの変形が施され る時に、すでにそのレスポンスにこの Wanring コードが与えられている場 合以外は、これが中間のキャッシュかプロクシによって追加されなければ *ならない*。 299 Miscellaneous persistent warning この警告文には、それを人間ユーザに表示、記録させるために独自の情報 を含む事が *できる*。この警告を受けたシステムは、どんな自動的なアク ションも起こし *てはならない*。 もしインプリメンテーションが HTTP/1.0 以下のバージョンの一つ以上の Warning ヘッダを持ったメッセージを送ったならば、送信者はそれぞれの warning-value にレスポンスの時刻に一致する warn-date を含ま *なければ ならない*。 もしインプリメンテーションが warn-date 付きの warning-value を持つメ ッセージを受け取り、その warn-date がレスポンス中の Date 値と異なって いたとしたら、それを保存、転送、使用する前にメッセージからその warning-value を消去し *なければならない*。 (これは、無用心なキャッシ ュが Warning ヘッダフィールドを処理した時に好ましくない結果を引き起こ す事を防止する。) この理由によりすべての warning-value が消去されたな らば、同様にして Waning ヘッダも消去され *なければならない*。 14.47 WWW-Authenticate WWW-Authenticate レスポンスヘッダフィールドは、401 (Unauthorized) レ スポンスメッセージ中に含まれてい *なければならない*。このフィールド値 は、その Request-URI に適用できる認証スキームとパラメータを示す最低一 つの challenge から成る。 WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge HTTP アクセス認証処理方法については、"HTTP Authentication: Basic and Digest Access Authentication" [43] にて記述されている。ユーザエージェ ントは、それが複数の challenge を含んでいる、あるいは複数の WWW- Authenticate ヘッダフィールドを含んでいても、challenge の内容にコンマ で分けられた認証パラメータのリストを含んでいるかもしれないので、WWW- Authenticate フィールド値を解析するのには特別な注意を払うべきである。