10. メッセージコンテキスト (Message Context)

10.1. リクエストコンテキストフィールド (Request Context Fields)

以下のリクエストヘッダフィールドは、ユーザー、ユーザーエージェント、リクエストの背後にあるリソースに関する情報を含む、リクエストコンテキストに関する追加情報を提供します。

10.1.1. Expect

リクエスト内の「Expect」ヘッダフィールドは、このリクエストを適切に処理するためにサーバーがサポートする必要がある特定の動作のセット（期待値）を示します。

Expect =      #expectation
expectation = token [ "=" ( token / quoted-string ) parameters ]

Expectフィールド値は大文字小文字を区別しません。

この仕様で定義されている唯一の期待値は「100-continue」です（定義されたパラメータはありません）。

100-continue以外のメンバーを含むExpectフィールド値を受信したサーバーは、予期しない期待値を満たすことができないことを示すために、417（Expectation Failed）ステータスコードで応答してもかまいません（MAY）。

「100-continue」期待値は、クライアントがこのリクエストで（おそらく大きな）コンテンツを送信しようとしており、メソッド、ターゲットURI、ヘッダフィールドが即座の成功、リダイレクト、またはエラー応答を引き起こすのに十分でない場合に100（Continue）暫定応答を受信したいことを受信者に通知します。これにより、クライアントは実際にコンテンツを送信する前に、コンテンツを送信する価値があるかどうかの指示を待つことができます。データが巨大な場合、またはクライアントがエラーが発生する可能性が高いと予想する場合（例えば、以前に検証された認証資格情報なしで状態変更メソッドを送信する場合）に効率を向上させることができます。

例えば、以下で始まるリクエスト

PUT /somewhere/fun HTTP/1.1
Host: origin.example.com
Content-Type: video/h264
Content-Length: 1234567890987
Expect: 100-continue

は、クライアントが不要なデータ転送でパイプを埋め始める前に、オリジンサーバーが401（Unauthorized）や405（Method Not Allowed）などのエラーメッセージで即座に応答することを可能にします。

クライアントの要件：

• クライアントは、コンテンツを含まないリクエストで100-continue期待値を生成してはなりません（MUST NOT）。
• リクエストコンテンツを送信する前に100（Continue）応答を待つクライアントは、100-continue期待値を含むExpectヘッダフィールドを送信しなければなりません（MUST）。
• 100-continue期待値を送信するクライアントは、特定の時間の長さを待つ必要はありません。そのようなクライアントは、まだ応答を受信していない場合でも、コンテンツの送信を続行してもかまいません（MAY）。さらに、100（Continue）応答はHTTP/1.0仲介者を通じて送信できないため、そのようなクライアントは、コンテンツを送信する前に無期限に待つべきではありません（SHOULD NOT）。
• 100-continue期待値を含むリクエストに対する応答として417（Expectation Failed）ステータスコードを受信したクライアントは、100-continue期待値なしでそのリクエストを繰り返すべきです（SHOULD）。417応答は、応答チェーンが期待値をサポートしていないことを示すだけだからです（例えば、HTTP/1.0サーバーを通過する場合）。

サーバーの要件：

• HTTP/1.0リクエストで100-continue期待値を受信したサーバーは、その期待値を無視しなければなりません（MUST）。
• サーバーが対応するリクエストのコンテンツの一部または全部を既に受信している場合、またはフレーミングがコンテンツがないことを示している場合、サーバーは100（Continue）応答の送信を省略してもかまいません（MAY）。
• 100（Continue）応答を送信するサーバーは、リクエストコンテンツを受信して処理した後、接続が早期に閉じられない限り、最終的に最終ステータスコードを送信しなければなりません（MUST）。
• リクエストコンテンツ全体を読み取る前に最終ステータスコードで応答するサーバーは、接続を閉じるつもりかどうか（例えば、[HTTP/1.1]のセクション9.6を参照）、またはリクエストコンテンツの読み取りを続けるつもりかどうかを示すべきです（SHOULD）。

メソッド、ターゲットURI、および100-continue期待値を含み、リクエストコンテンツが続くことを示す完全なヘッダセクションを持つHTTP/1.1（またはそれ以降）リクエストを受信した場合、オリジンサーバーは次のいずれかを送信しなければなりません（MUST）：

• メソッド、ターゲットURI、ヘッダフィールドのみを検査することでそのステータスを判断できる場合は、最終ステータスコードでの即座の応答、または
• クライアントにリクエストコンテンツの送信を促すための即座の100（Continue）応答。

オリジンサーバーは、100（Continue）応答を送信する前にコンテンツを待ってはなりません（MUST NOT）。

メソッド、ターゲットURI、および100-continue期待値を含み、リクエストコンテンツが続くことを示す完全なヘッダセクションを持つHTTP/1.1（またはそれ以降）リクエストを受信した場合、プロキシは次のいずれかを行わなければなりません（MUST）：

• メソッド、ターゲットURI、ヘッダフィールドのみを検査することでそのステータスを判断できる場合は、最終ステータスコードでの即座の応答を送信する、または
• 次のインバウンドサーバーに対応するリクエスト行とヘッダセクションを送信することにより、オリジンサーバーに向けてリクエストを転送する。

プロキシが（設定または過去のやり取りから）次のインバウンドサーバーがHTTP/1.0のみをサポートしていると信じている場合、プロキシはクライアントにコンテンツの送信を開始させるために即座の100（Continue）応答を生成してもかまいません（MAY）。

10.1.2. From

「From」ヘッダフィールドには、リクエストしているユーザーエージェントを制御する人間ユーザーのインターネット電子メールアドレスが含まれます。このアドレスは、[RFC5322]のセクション3.4で「mailbox」として定義されているように、機械で使用可能である必要があります。

From    = mailbox

mailbox = <mailbox, see [RFC5322], Section 3.4>

例：

From: [email protected]

Fromヘッダフィールドは、ロボット以外のユーザーエージェントによって送信されることはめったにありません。ユーザーエージェントは、ユーザーの明示的な設定なしにFromヘッダフィールドを送信すべきではありません（SHOULD NOT）。これは、ユーザーのプライバシーの利益やサイトのセキュリティポリシーと矛盾する可能性があるためです。

ロボットユーザーエージェントは、サーバーで問題が発生した場合にロボットの実行を担当する人に連絡できるように、有効なFromヘッダフィールドを送信すべきです（SHOULD）。例えば、ロボットが過剰な、不要な、または無効なリクエストを送信している場合などです。

サーバーは、Fromヘッダフィールドをアクセス制御や認証に使用すべきではありません（SHOULD NOT）。その値は、リクエストを受信または観察する人なら誰でも見ることができ、通常はプライバシーの期待なしにログファイルやエラーレポートに記録されることが期待されるためです。

10.1.3. Referer

「Referer」[原文ママ]ヘッダフィールドにより、ユーザーエージェントは、ターゲットURIが取得されたリソースのURI参照を指定できます（つまり、「参照元（referrer）」ですが、フィールド名のスペルが間違っています）。ユーザーエージェントは、Refererフィールド値を生成する際に、URI参照[URI]のフラグメントおよびuserinfoコンポーネント（存在する場合）を含めてはなりません（MUST NOT）。

Referer = absolute-URI / partial-URI

フィールド値は、absolute-URIまたはpartial-URIのいずれかです。後者の場合（セクション4）、参照されるURIはターゲットURIに対して相対的です（[URI]、セクション5）。

Refererヘッダフィールドにより、サーバーは、簡単な分析、ログ記録、最適化されたキャッシングなどのために、他のリソースへのバックリンクを生成できます。また、メンテナンスのために、古いリンクや誤植のあるリンクを見つけることもできます。一部のサーバーは、Refererヘッダフィールドを、他のサイトからのリンク（いわゆる「ディープリンク」）を拒否したり、クロスサイトリクエストフォージェリ（CSRF）を制限したりする手段として使用しますが、すべてのリクエストにこれが含まれているわけではありません。

例：

Referer: http://www.example.org/hypertext/Overview.html

ターゲットURIが独自のURIを持たないソース（例えば、ユーザーキーボードからの入力、またはユーザーのブックマーク/お気に入りのエントリ）から取得された場合、ユーザーエージェントはRefererヘッダフィールドを除外するか、「about:blank」の値で送信しなければなりません（MUST）。

Refererヘッダフィールド値は、参照リソースの完全なURIを伝える必要はありません。ユーザーエージェントは、参照元以外の部分を切り詰めてもかまいません（MAY）。

参照リソースの識別子が個人情報（アカウント名など）を漏らす場合、または機密にすべきリソース（ファイアウォールの背後やセキュアなサービス内部など）の場合、Refererヘッダフィールドは、リクエストコンテキストやユーザーのブラウジング履歴に関する情報を漏らす可能性があり、これはプライバシー上の懸念です。ほとんどの汎用ユーザーエージェントは、参照リソースがローカルの「file」または「data」URIの場合、Refererヘッダフィールドを送信しません。ユーザーエージェントは、参照リソースがセキュアプロトコルを使用してアクセスされ、リクエストターゲットのオリジンが参照リソースのオリジンと異なる場合、参照リソースが明示的にRefererの送信を許可しない限り、Refererヘッダフィールドを送信すべきではありません（SHOULD NOT）。ユーザーエージェントは、参照リソースがセキュアプロトコルを使用してアクセスされた場合、セキュアでないHTTPリクエストでRefererヘッダフィールドを送信してはなりません（MUST NOT）。追加のセキュリティ上の考慮事項については、セクション17.9を参照してください。

一部の仲介者は、送信リクエストからRefererヘッダフィールドを無差別に削除することが知られています。これには、CSRF攻撃に対する保護を妨げるという不幸な副作用があり、ユーザーにとってはるかに有害な可能性があります。Refererでの情報開示を制限したい仲介者およびユーザーエージェント拡張機能は、内部ドメイン名を仮名に置き換えたり、クエリおよび/またはパスコンポーネントを切り詰めたりするなど、特定の編集に変更を制限すべきです。仲介者は、フィールド値がリクエストターゲットと同じスキームとホストを共有している場合、Refererヘッダフィールドを変更または削除すべきではありません（SHOULD NOT）。

10.1.4. TE

「TE」ヘッダフィールドは、転送コーディングとトレーラセクションに関するクライアントの機能を記述します。

セクション6.5で説明されているように、リクエストで「trailers」メンバーを含むTEフィールドを送信することは、クライアントがトレーラフィールドを破棄しないことを示します。

TEは、HTTP/1.1でも使用され、クライアントが応答で受け入れることができる転送コーディングをサーバーに通知します。公開時点では、HTTP/1.1のみが転送コーディングを使用しています（[HTTP/1.1]のセクション7を参照）。

TEフィールド値はメンバーのリストであり、各メンバー（「trailers」以外）は、転送コーディング名トークンと、その転送コーディングに対するクライアントの相対的な優先度を示すオプションの重み（セクション12.4.2）、およびその転送コーディングのオプションのパラメータで構成されます。

TE                 = #t-codings
t-codings          = "trailers" / ( transfer-coding [ weight ] )
transfer-coding    = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = token BWS "=" BWS ( token / quoted-string )

TEの送信者は、そのセマンティクスをサポートしていない仲介者によってTEフィールドが転送されるのを防ぐために、Connectionヘッダフィールド（セクション7.6.1）で「TE」接続オプションも送信しなければなりません（MUST）。

10.1.5. User-Agent

「User-Agent」ヘッダフィールドには、リクエストを発信したユーザーエージェントに関する情報が含まれており、サーバーは通常、報告された相互運用性の問題の範囲を特定したり、特定のユーザーエージェントの制限を回避または調整したりするために使用します。また、ブラウザやオペレーティングシステムの使用に関する分析にも使用されます。ユーザーエージェントは、特に設定されていない限り、各リクエストでUser-Agentヘッダフィールドを送信すべきです（SHOULD）。

User-Agent = product *( RWS ( product / comment ) )

User-Agentフィールド値は、1つ以上の製品識別子で構成され、それぞれの後に0個以上のコメント（セクション5.6.5）が続きます。これらは一緒になって、ユーザーエージェントソフトウェアとその重要なサブ製品を識別します。慣例により、製品識別子は、ユーザーエージェントソフトウェアを識別する上での重要性の降順にリストされます。各製品識別子は、名前とオプションのバージョンで構成されます。

product         = token ["/" product-version]
product-version = token

送信者は、生成される製品識別子を製品の識別に必要なものに制限すべきであり（SHOULD）、製品識別子内に広告やその他の不要な情報を生成してはなりません（MUST NOT）。送信者は、バージョン識別子でない情報をproduct-versionで生成すべきではありません（SHOULD NOT）（つまり、同じ製品名の連続したバージョンは、製品識別子のproduct-version部分のみが異なるべきです）。

例：

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

ユーザーエージェントは、不必要に細かい詳細を含むUser-Agentヘッダフィールドを生成すべきではなく（SHOULD NOT）、サードパーティによるサブ製品の追加を制限すべきです（SHOULD）。過度に長く詳細なUser-Agentフィールド値は、リクエスト遅延を増加させ、ユーザーが意図に反して識別される（「フィンガープリンティング」）リスクを高めます。

同様に、実装は、互換性を宣言するために他の実装の製品トークンを使用しないことが推奨されます。これは、フィールドの目的を回避するためです。ユーザーエージェントが別のユーザーエージェントを装う場合、受信者は、ユーザーが意図的にその識別されたユーザーエージェント向けにカスタマイズされた応答を見たいと望んでいると仮定できます。たとえそれらが実際に使用されているユーザーエージェントにはあまり適していない可能性があるとしてもです。

10.2. レスポンスコンテキストフィールド (Response Context Fields)

以下の応答ヘッダフィールドは、ステータスコードによって暗示されるものを超えて、サーバー、ターゲットリソース、または関連リソースに関する情報を含む、応答に関する追加情報を提供します。

10.2.1. Allow

「Allow」ヘッダフィールドは、ターゲットリソースによってサポートされているとアドバタイズされるメソッドのセットをリストします。このフィールドの目的は、リソースに関連付けられた有効なリクエストメソッドを受信者に通知することに厳密に限定されています。

Allow = #method

使用例：

Allow: GET, HEAD, PUT

実際に許可されるメソッドのセットは、各リクエスト時にオリジンサーバーによって定義されます。オリジンサーバーは、405（Method Not Allowed）応答でAllowヘッダフィールドを生成しなければならず（MUST）、他の応答でもそうしてもかまいません（MAY）。空のAllowフィールド値は、リソースがどのメソッドも許可しないことを示します。これは、リソースが設定によって一時的に無効にされている405応答で発生する可能性があります。

プロキシは、Allowヘッダフィールドを変更してはなりません（MUST NOT）。一般的なメッセージ処理ルールに従ってそれらを処理するために、示されているすべてのメソッドを理解する必要はありません。

10.2.2. Location

「Location」ヘッダフィールドは、応答に関連する特定のリソースを参照するために、一部の応答で使用されます。関係のタイプは、リクエストメソッドとステータスコードセマンティクスの組み合わせによって定義されます。

Location = URI-reference

フィールド値は、単一のURI-referenceで構成されます。相対参照の形式（[URI]、セクション4.2）を持つ場合、最終値はターゲットURIに対してそれを解決することによって計算されます（[URI]、セクション5）。

201（Created）応答の場合、Location値はリクエストによって作成された主要なリソースを参照します。3xx（Redirection）応答の場合、Location値はリクエストを自動的にリダイレクトするための優先ターゲットリソースを参照します。

3xx（Redirection）応答で提供されるLocation値にフラグメントコンポーネントがない場合、ユーザーエージェントは、その値がターゲットURIを生成するために使用されたURI参照のフラグメントコンポーネントを継承しているかのようにリダイレクトを処理しなければなりません（MUST）（つまり、リダイレクトは元の参照のフラグメントを継承します（存在する場合））。

例えば、URI参照「http://www.example.org/~tim」に対して生成されたGETリクエストは、次のヘッダフィールドを含む303（See Other）応答を生じる可能性があります：

Location: /People.html#tim

これは、ユーザーエージェントが「http://www.example.org/People.html#tim」にリダイレクトすることを提案します。

同様に、URI参照「http://www.example.org/index.html#larry」に対して生成されたGETリクエストは、次のヘッダフィールドを含む301（Moved Permanently）応答を生じる可能性があります：

Location: http://www.example.net/index.html

これは、ユーザーエージェントが「http://www.example.net/index.html#larry」にリダイレクトし、元のフラグメント識別子を保持することを提案します。

Location値のフラグメント識別子が不適切な状況があります。例えば、201（Created）応答のLocationヘッダフィールドは、作成されたリソースに固有のURIを提供する必要があります。

注意： 一部の受信者は、有効なURI参照ではないLocationヘッダフィールドから回復しようとします。この仕様は、そのような処理を義務付けたり定義したりしませんが、堅牢性のためにそれを許可します。Locationフィールド値は、メンバーのリストを許可できません。カンマリスト区切り文字はURI-reference内の有効なデータ文字だからです。複数のLocationフィールド行を持つ無効なメッセージが送信された場合、受信者はそれらのフィールド行を1つの値に結合する可能性があります。パスに沿った回復は、これらのフィールド行を1つの値に結合する可能性があります。このような状況から有効なLocationフィールド値を回復することは困難であり、実装間で相互運用できません。

注意： Content-Locationヘッダフィールド（セクション8.7）は、Content-Locationが含まれる表現に対応する最も具体的なリソースを参照する点でLocationとは異なります。したがって、応答にはLocationヘッダフィールドとContent-Locationヘッダフィールドの両方が含まれる可能性があります。

10.2.3. Retry-After

サーバーは「Retry-After」ヘッダフィールドを送信して、ユーザーエージェントが後続のリクエストを行う前にどのくらい待つべきかを示します。503（Service Unavailable）応答とともに送信された場合、Retry-Afterは、サービスがクライアントに対して利用できないと予想される期間を示します。任意の3xx（Redirection）応答とともに送信された場合、Retry-Afterは、リダイレクトされたリクエストを発行する前にユーザーエージェントが待つように求められる最小時間を示します。

Retry-Afterフィールド値は、HTTP-dateまたは応答を受信した後の遅延秒数のいずれかです。

Retry-After = HTTP-date / delay-seconds

delay-seconds値は、秒単位の時間を表す非負の10進整数です。

delay-seconds  = 1*DIGIT

その使用の2つの例は

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

後者の例では、遅延は2分です。

10.2.4. Server

「Server」ヘッダフィールドには、リクエストを処理するためにオリジンサーバーが使用したソフトウェアに関する情報が含まれており、クライアントは通常、報告された相互運用性の問題の範囲を特定したり、特定のサーバーの制限を回避または調整したりするために使用します。また、サーバーやオペレーティングシステムの使用に関する分析にも使用されます。オリジンサーバーは、その応答でServerヘッダフィールドを生成してもかまいません（MAY）。

Server = product *( RWS ( product / comment ) )

Serverヘッダフィールド値は、1つ以上の製品識別子で構成され、それぞれの後に0個以上のコメント（セクション5.6.5）が続きます。これらは一緒になって、オリジンサーバーソフトウェアとその重要なサブ製品を識別します。慣例により、製品識別子は、オリジンサーバーソフトウェアを識別する上での重要性の降順にリストされます。各製品識別子は、セクション10.1.5で定義されているように、名前とオプションのバージョンで構成されます。

例：

Server: CERN/3.0 libwww/2.17

オリジンサーバーは、不必要に細かい詳細を含むServerヘッダフィールドを生成すべきではなく（SHOULD NOT）、サードパーティによるサブ製品の追加を制限すべきです（SHOULD）。過度に長く詳細なServerフィールド値は、応答遅延を増加させ、攻撃者が既知のセキュリティホールを見つけて悪用することを（わずかに）容易にする可能性のある内部実装の詳細を明らかにする可能性があります。