メインコンテンツまでスキップ

12. コンテンツネゴシエーション (Content Negotiation)

レスポンスがコンテンツを伝達する場合、成功またはエラーを示すかどうかにかかわらず、オリジンサーバーは多くの場合、その情報を表現するためのさまざまな方法を持っています。たとえば、異なる形式、言語、またはエンコーディングなどです。同様に、異なるユーザーまたはユーザーエージェントは、利用可能な表現のうちどれが配信に最適かに影響を与える可能性のある、異なる機能、特性、または設定を持つ場合があります。このため、HTTPはコンテンツネゴシエーションのメカニズムを提供します。

この仕様は、プロトコル内で可視化される3つのコンテンツネゴシエーションパターンを定義します：「プロアクティブ」ネゴシエーション（サーバーがユーザーエージェントの表明された設定に基づいて表現を選択する）、「リアクティブ」ネゴシエーション（サーバーがユーザーエージェントが選択するための表現のリストを提供する）、および「リクエストコンテンツ」ネゴシエーション（ユーザーエージェントが過去のレスポンスでサーバーが表明した設定に基づいて、将来のリクエストの表現を選択する）。

他のコンテンツネゴシエーションパターンには、「条件付きコンテンツ」（表現がユーザーエージェントパラメータに基づいて選択的にレンダリングされる複数の部分で構成される）、「アクティブコンテンツ」（表現にユーザーエージェントの特性に基づいて追加の（より具体的な）リクエストを行うスクリプトが含まれる）、および「透過的コンテンツネゴシエーション」（[RFC2295]、コンテンツ選択が仲介者によって実行される）が含まれます。これらのパターンは相互に排他的ではなく、それぞれが適用性と実用性においてトレードオフを持っています。

すべての場合において、HTTPはリソースのセマンティクスを認識していないことに注意してください。オリジンサーバーがリクエストに対して応答する一貫性、時間の経過およびさまざまなクライアントに対して、したがってリソースの観察された表現の時間の経過における「同一性」は、これらのレスポンスを選択または生成するエンティティまたはアルゴリズムによって完全に決定されます。

12.1. プロアクティブネゴシエーション (Proactive Negotiation)​

コンテンツネゴシエーションの設定がユーザーエージェントによってリクエストで送信され、サーバーに配置されたアルゴリズムが優先表現を選択することを促す場合、これは「プロアクティブネゴシエーション」（別名「サーバー駆動ネゴシエーション」）と呼ばれます。選択は、レスポンスの利用可能な表現（言語、コンテンツコーディングなど、変化する可能性のある次元）を、リクエストで提供されるさまざまな情報と比較することに基づいています。これには、以下の明示的なネゴシエーションフィールドと、クライアントのネットワークアドレスやUser-Agentフィールドの一部などの暗黙的な特性の両方が含まれます。

利用可能な表現から選択するアルゴリズムがユーザーエージェントに説明するのが難しい場合、または、サーバーが最初のレスポンスとともに「最良の推測」をユーザーエージェントに送信したい場合（その「最良の推測」がユーザーにとって十分に良好である場合、後続のリクエストのラウンドトリップ遅延を回避する）、プロアクティブネゴシエーションは有利です。サーバーの推測を改善するために、ユーザーエージェントはその設定を説明するリクエストヘッダフィールドを送信してもかまいません（MAY）。

プロアクティブネゴシエーションには重大な欠点があります：

  • サーバーが特定のユーザーにとって何が「最良」であるかを正確に判断することは不可能です。なぜなら、それにはユーザーエージェントの機能とレスポンスの意図された使用の両方の完全な知識が必要だからです（たとえば、ユーザーは画面で表示したいのか、紙に印刷したいのか？）。

  • ユーザーエージェントが毎回のリクエストでその機能を説明することは、非常に非効率的である可能性があり（複数の表現を持つレスポンスはごく一部であることを考慮すると）、ユーザーのプライバシーに対する潜在的なリスクとなります。

  • オリジンサーバーの実装と、リクエストに対するレスポンスを生成するアルゴリズムを複雑にします。

  • 共有キャッシュのレスポンスの再利用性を制限します。

ユーザーエージェントは、プロアクティブネゴシエーションの設定が一貫して尊重されることに依存できません。なぜなら、オリジンサーバーがリクエストされたリソースに対してプロアクティブネゴシエーションを実装していない可能性があるか、ユーザーエージェントの設定に準拠しないレスポンスを送信することが406（Not Acceptable）レスポンスを送信するよりも良いと判断する可能性があるためです。

Varyヘッダフィールド（セクション12.5.5）は、プロアクティブネゴシエーションの影響を受けるレスポンスで送信されることが多く、選択アルゴリズムでリクエスト情報のどの部分が使用されたかを示します。

リクエストヘッダフィールドAccept、Accept-Charset、Accept-Encoding、およびAccept-Languageは、ユーザーエージェントがレスポンスコンテンツのプロアクティブネゴシエーションに参加するために以下で定義されています。これらのフィールドで送信される設定は、ターゲットリソースの表現、エラーまたは処理ステータスの表現、さらにはプロトコル内に表示される可能性のあるさまざまなテキスト文字列を含む、レスポンス内の任意のコンテンツに適用されます。

12.2. リアクティブネゴシエーション (Reactive Negotiation)​

「リアクティブネゴシエーション」（別名「エージェント駆動ネゴシエーション」）を使用すると、コンテンツの選択（ステータスコードに関係なく）は、初期レスポンスを受信した後にユーザーエージェントによって実行されます。リアクティブネゴシエーションのメカニズムは、代替表現への参照のリストと同じくらい単純な場合があります。

ユーザーエージェントが初期レスポンスコンテンツに満足していない場合、異なる表現を取得するために、1つ以上の代替リソースに対してGETリクエストを実行できます。このような代替の選択は、（ユーザーエージェントによって）自動的に、または（たとえば、ユーザーがハイパーテキストメニューから選択することによって）手動で実行される可能性があります。

サーバーは、代替のリスト以外の初期表現を送信しないことを選択でき、したがって、ユーザーエージェントによるリアクティブネゴシエーションが優先されることを示す場合があります。たとえば、300（Multiple Choices）および406（Not Acceptable）ステータスコードを持つレスポンスにリストされている代替には、利用可能な表現に関する情報が含まれているため、ユーザーまたはユーザーエージェントは選択を行うことで反応できます。

レスポンスが一般的に使用される次元（タイプ、言語、またはエンコーディングなど）で変化する場合、オリジンサーバーがリクエストを調べることでユーザーエージェントの機能を判断できない場合、および一般的にパブリックキャッシュがサーバー負荷を分散し、ネットワーク使用量を削減するために使用される場合、リアクティブネゴシエーションは有利です。

リアクティブネゴシエーションには、ユーザーエージェントに代替のリストを送信することの欠点があります。これは、ヘッダセクションで送信される場合、ユーザーが認識する遅延を低下させ、代替表現を取得するために2番目のリクエストが必要になります。さらに、この仕様は自動選択をサポートするメカニズムを定義していませんが、そのようなメカニズムの開発を妨げるものではありません。

12.3. リクエストコンテンツネゴシエーション (Request Content Negotiation)​

コンテンツネゴシエーションの設定がサーバーによってレスポンスで送信される場合、リストされた設定は「リクエストコンテンツネゴシエーション」と呼ばれます。なぜなら、それらはそのリソースへの後続のリクエストに適切なコンテンツの選択に影響を与えることを意図しているためです。たとえば、Accept（セクション12.5.1）およびAccept-Encoding（セクション12.5.3）ヘッダフィールドは、そのリソースへの後続のリクエストの優先メディアタイプとコンテンツコーディングを示すために、レスポンスで送信できます。

同様に、[RFC5789]のセクション3.1は、「Accept-Patch」レスポンスヘッダフィールドを定義しており、PATCHリクエストで受け入れられるコンテンツタイプの発見を可能にします。

12.4. コンテンツネゴシエーションフィールドの機能 (Content Negotiation Field Features)​

12.4.1. 不在 (Absence)​

各コンテンツネゴシエーションフィールドについて、そのフィールドを含まないリクエストは、送信者がそのネゴシエーション次元について設定を持っていないことを意味します。

コンテンツネゴシエーションヘッダフィールドがリクエストに存在し、レスポンスの利用可能な表現のいずれもそれに従って受け入れ可能と見なされない場合、オリジンサーバーは406（Not Acceptable）レスポンスを送信することでヘッダフィールドを尊重するか、そのリクエストヘッダフィールドのコンテンツネゴシエーションの対象ではないかのようにレスポンスを扱うことでヘッダフィールドを無視できます。ただし、これはクライアントがその表現を使用できることを意味するものではありません。

注意： これらのヘッダフィールドを送信するユーザーエージェントは、ユーザーエージェントのリクエスト特性によって個人を識別することをサーバーにとってより容易にします（セクション17.13）。

12.4.2. 品質値 (Quality Values)​

この仕様で定義されるコンテンツネゴシエーションフィールドは、「q」という名前の共通パラメータ（大文字小文字を区別しない）を使用して、その関連するコンテンツの種類の設定に相対的な「重み」を割り当てます。この重みは「品質値」（または「qvalue」）と呼ばれます。これは、同じパラメータ名がリソースに対して選択できるさまざまな表現の相対的な品質に重みを割り当てるためにサーバー構成内でよく使用されるためです。

重みは、0から1の範囲の実数に正規化されます。0.001が最も好ましくなく、1が最も好ましいものです。値0は「受け入れられない」を意味します。「q」パラメータが存在しない場合、デフォルトの重みは1です。

weight = OWS ";" OWS "q=" qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] )
       / ( "1" [ "." 0*3("0") ] )

qvalueの送信者は、小数点の後に3桁を超える数字を生成してはなりません（MUST NOT）。これらの値のユーザー構成は、同じ方法で制限されるべきです。

12.4.3. ワイルドカード値 (Wildcard Values)​

これらのヘッダフィールドのほとんど（示されている場所）は、指定されていない値を選択するためのワイルドカード値（*）を定義しています。ワイルドカードが存在しない場合、フィールドで明示的に言及されていない値は受け入れられないと見なされます。Vary内では、ワイルドカード値は変化が無制限であることを意味します。

注意： 実際には、コンテンツネゴシエーションでワイルドカードを使用することの実用的価値は限られています。なぜなら、たとえば「私はimage/*を（他の特定の値）よりも多く、または少なく好む」と言うことが役立つことはめったにないためです。Accept: */*;q=0を送信することにより、クライアントは、より優先される形式が利用できない場合に406（Not Acceptable）レスポンスを明示的に要求できますが、サーバーがその設定を無視することが許可されているため、異なるレスポンスを処理できる必要があります。

12.5. コンテンツネゴシエーションフィールド (Content Negotiation Fields)​

12.5.1. Accept​

「Accept」ヘッダフィールドは、ユーザーエージェントがレスポンスメディアタイプに関する設定を指定するために使用できます。たとえば、Acceptヘッダフィールドは、インライン画像のリクエストの場合のように、リクエストが特に希望するタイプの小さなセットに限定されることを示すために使用できます。

サーバーによってレスポンスで送信される場合、Acceptは、同じリソースへの後続のリクエストのコンテンツでどのコンテンツタイプが優先されるかに関する情報を提供します。

Accept = #( media-range [ weight ] )

media-range    = ( "*/*"
                   / ( type "/" "*" )
                   / ( type "/" subtype )
                 ) parameters

アスタリスク*文字は、メディアタイプを範囲にグループ化するために使用され、*/*はすべてのメディアタイプを示し、type/*はそのタイプのすべてのサブタイプを示します。media-rangeには、その範囲に適用可能なメディアタイプパラメータを含めることができます。

各media-rangeの後には、オプションの適用可能なメディアタイプパラメータ（たとえば、charset）が続き、次に相対的な重みを示すためのオプションの「q」パラメータ（セクション12.4.2）が続きます。

以前の仕様では、重みパラメータの後に追加の拡張パラメータが表示されることが許可されていました。accept拡張構文（accept-params、accept-ext）は、複雑な定義を持ち、実際には使用されておらず、新しいヘッダフィールドを介してより簡単にデプロイできるため、削除されました。重みを使用する送信者は、「q」を最後に（すべてのmedia-rangeパラメータの後に）送信すべきです（SHOULD）。受信者は、パラメータの順序に関係なく、「q」という名前の任意のパラメータを重みとして処理すべきです（SHOULD）。

注意： 「q」パラメータ名を使用してコンテンツネゴシエーションを制御すると、同じ名前を持つメディアタイプパラメータに干渉します。したがって、メディアタイプレジストリは「q」という名前のパラメータを許可しません。

例：

Accept: audio/*; q=0.2, audio/basic

は、「私はaudio/basicを好みますが、80％の品質低下後に利用可能な最良のものである場合は、任意のオーディオタイプを送信してください」と解釈されます。

より精巧な例は：

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/plain, text/plain;format=flowed, */*

には、次の優先順位があります：

  1. text/plain;format=flowed
  2. text/plain
  3. text/*
  4. */*

特定のタイプに関連付けられたメディアタイプ品質因子は、そのタイプに一致する最も高い優先順位を持つメディア範囲を見つけることによって決定されます。例えば：

Accept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed,
       text/plain;format=fixed;q=0.4, */*;q=0.5

は、次の値が関連付けられます：

メディアタイプ品質値
text/plain;format=flowed1
text/plain0.7
text/html0.3
image/jpeg0.5
text/plain;format=fixed0.4
text/html;level=30.7

注意： ユーザーエージェントには、特定のメディア範囲のデフォルトの品質値セットが提供される場合があります。ただし、ユーザーエージェントが他のレンダリングエージェントと相互作用できない閉じたシステムでない限り、このデフォルトセットはユーザーが構成できるべきです。

12.5.2. Accept-Charset​

「Accept-Charset」ヘッダフィールドは、ユーザーエージェントがテキストレスポンスコンテンツの文字セットに関する設定を示すために送信できます。たとえば、このフィールドにより、より包括的または特殊な目的の文字セットを理解できるユーザーエージェントは、それらの文字セットで情報を表現できるオリジンサーバーにその能力を通知できます。

Accept-Charset = #( ( token / "*" ) [ weight ] )

文字セット名はセクション8.3.2で定義されています。ユーザーエージェントは、セクション12.4.2で定義されているように、その文字セットに対するユーザーの相対的な設定を示すために、各文字セットに品質値を関連付けてもかまいません（MAY）。例は：

Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

特別な値*は、Accept-Charsetヘッダフィールドに存在する場合、フィールド内の他の場所で言及されていないすべての文字セットに一致します。

注意： Accept-Charsetは非推奨です。なぜなら、UTF-8がほぼ遍在するようになり、ユーザーの優先文字セットの詳細なリストを送信することは帯域幅を浪費し、遅延を増加させ、パッシブフィンガープリンティングを非常に容易にするためです（セクション17.13）。ほとんどの汎用ユーザーエージェントは、特に構成されていない限り、Accept-Charsetを送信しません。

12.5.3. Accept-Encoding​

「Accept-Encoding」ヘッダフィールドは、コンテンツコーディングの使用に関する設定を示すために使用できます（セクション8.4.1）。

ユーザーエージェントによってリクエストで送信される場合、Accept-Encodingはレスポンスで受け入れ可能なコンテンツコーディングを示します。

サーバーによってレスポンスで送信される場合、Accept-Encodingは、同じリソースへの後続のリクエストのコンテンツでどのコンテンツコーディングが優先されるかに関する情報を提供します。

「identity」トークンは、エンコーディングが優先されない場合に通信するために、「エンコーディングなし」の同義語として使用されます。

Accept-Encoding  = #( codings [ weight ] )
codings          = content-coding / "identity" / "*"

各codings値には、セクション12.4.2で定義されているように、そのエンコーディングに対する設定を表す関連する品質値（重み）を与えてもかまいません（MAY）。Accept-Encodingフィールドのアスタリスク*記号は、フィールドに明示的にリストされていない利用可能なコンテンツコーディングに一致します。

例：

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

サーバーは、次のルールを使用して、特定の表現のコンテンツコーディングが受け入れ可能かどうかをテストします：

  1. リクエストにAccept-Encodingヘッダフィールドがない場合、ユーザーエージェントは任意のコンテンツコーディングが受け入れ可能であると見なします。

  2. 表現にコンテンツコーディングがない場合、Accept-Encodingヘッダフィールドがidentity;q=0または*;q=0を宣言し、より具体的な「identity」エントリがない限り、明示的に除外しない限り、デフォルトで受け入れ可能です。

  3. 表現のコンテンツコーディングがAccept-Encodingフィールド値にリストされているコンテンツコーディングの1つである場合、それはqvalue 0を伴わない限り受け入れ可能です。（セクション12.4.2で定義されているように、qvalue 0は「受け入れられない」を意味します。）

表現は複数のコンテンツコーディングでエンコードできます。ただし、ほとんどのコンテンツコーディングは同じ目的を達成するための代替方法です（たとえば、データ圧縮）。同じ目的を持つ複数のコンテンツコーディング間で選択する場合、最も高いゼロ以外のqvalueを持つ受け入れ可能なコンテンツコーディングが優先されます。

空のフィールド値を持つAccept-Encodingヘッダフィールドは、ユーザーエージェントがレスポンス内に任意のコンテンツコーディングを望まないことを意味します。空でないAccept-Encodingヘッダフィールドがリクエストに存在し、レスポンスの利用可能な表現のいずれも受け入れ可能としてリストされているコンテンツコーディングを持たない場合、オリジンサーバーは、identityエンコーディングが受け入れられないと示されていない限り、コンテンツコーディングなしでレスポンスを送信すべきです（SHOULD）。

Accept-Encodingヘッダフィールドがレスポンスに存在する場合、リソースが関連するリクエストでどのコンテンツコーディングを受け入れる意思があったかを示します。フィールド値は、リクエストの場合と同じ方法で評価されます。

この情報は関連するリクエストに固有であることに注意してください。サポートされるエンコーディングのセットは、同じサーバー上の他のリソースでは異なる場合があり、時間の経過とともに変化したり、リクエストの他の側面（リクエストメソッドなど）に依存したりする可能性があります。

サポートされていないコンテンツコーディングのためにリクエストが失敗したサーバーは、415（Unsupported Media Type）ステータスで応答し、そのレスポンスにAccept-Encodingヘッダフィールドを含めて、クライアントがコンテンツコーディングとメディアタイプに関連する問題を区別できるようにすべきです。メディアタイプに関連する問題との混同を避けるために、コンテンツコーディングとは無関係な理由で415ステータスでリクエストを失敗させるサーバーは、Accept-Encodingヘッダフィールドを含めてはなりません（MUST NOT）。

Accept-Encodingの最も一般的な使用法は、クライアントによるコンテンツコーディングの楽観的な使用に応答して、415（Unsupported Media Type）ステータスコードを持つレスポンスです。ただし、ヘッダフィールドは、将来のインタラクションを最適化するために、コンテンツコーディングがサポートされていることをクライアントに示すためにも使用できます。たとえば、リクエストコンテンツが圧縮エンコーディングの使用を正当化するのに十分大きいが、クライアントがそうしなかった場合、リソースは2xx（Successful）レスポンスにそれを含めることができます。

12.5.4. Accept-Language​

「Accept-Language」ヘッダフィールドは、ユーザーエージェントがレスポンスで優先される自然言語のセットを示すために使用できます。言語タグはセクション8.5.1で定義されています。

Accept-Language = #( language-range [ weight ] )
language-range  =
          <language-range, see [RFC4647], Section 2.1>

各language-rangeには、セクション12.4.2で定義されているように、その範囲で指定された言語に対するユーザー設定の推定を表す関連する品質値を与えることができます。例えば：

Accept-Language: da, en-gb;q=0.8, en;q=0.7

は、「私はデンマーク語を好みますが、イギリス英語と他のタイプの英語も受け入れます」を意味します。

一部の受信者は、リストされた言語タグの順序を、特に同等の品質値が割り当てられたタグ（値がないものはq=1と同じ）に対する降順の優先度の指示として扱うことに注意してください。ただし、この動作に依存することはできません。一貫性と最大の相互運用性のために、多くのユーザーエージェントは各言語タグに一意の品質値を割り当てると同時に、品質の降順でリストします。言語優先順位リストの追加の議論については、[RFC4647]のセクション2.3を参照してください。

マッチングの場合、[RFC4647]のセクション3はいくつかのマッチングスキームを定義しています。実装は、そのニーズに最も適したマッチングスキームを提供できます。「基本フィルタリング」スキーム（[RFC4647]、セクション3.3.1）は、[RFC2616]のセクション14.4でHTTPに対して以前に定義されたマッチングスキームと同じです。

すべてのリクエストでユーザーの完全な言語設定を含むAccept-Languageヘッダフィールドを送信することは、ユーザーのプライバシー期待に反する可能性があります（セクション17.13）。

理解可能性は個々のユーザーに大きく依存するため、ユーザーエージェントはユーザーが言語設定を制御できるようにする必要があります（ユーザーエージェント自体の構成を通じて、またはユーザーが制御可能なシステム設定にデフォルトで設定することによって）。このような制御を提供しないユーザーエージェントは、Accept-Languageヘッダフィールドを送信してはなりません（MUST NOT）。

注意： ユーザーエージェントは、設定を設定する際にユーザーにガイダンスを提供すべきです。なぜなら、ユーザーは上記の言語マッチングの詳細にめったに精通していないためです。たとえば、ユーザーは「en-gb」を選択すると、イギリス英語が利用できない場合、任意の種類の英語文書を取得すると仮定する場合があります。このような場合、ユーザーエージェントは、より良いマッチング動作のためにリストに「en」を追加することを提案する場合があります。

12.5.5. Vary​

レスポンスの「Vary」ヘッダフィールドは、メソッドとターゲットURIを除いて、リクエストメッセージのどの部分がオリジンサーバーがこのレスポンスのコンテンツを選択するプロセスに影響を与えた可能性があるかを説明します。

Vary = #( "*" / field-name )

Varyフィールド値は、ワイルドカードメンバー*であるか、このレスポンスの表現を選択する際に役割を果たした可能性のある、選択ヘッダフィールドと呼ばれるリクエストfield-nameトークンのリストです。潜在的な選択ヘッダフィールドは、この仕様で定義されたフィールドに限定されません。

メンバー*を含むリストは、リクエストの他の側面がレスポンス表現の選択に役割を果たした可能性があることを示します。これには、メッセージ構文外の側面（たとえば、クライアントのネットワークアドレス）が含まれる可能性があります。受信者は、リクエストをオリジンサーバーに転送せずに、このレスポンスが後のリクエストに適切かどうかを判断できません。プロキシは、Varyフィールド値に*を生成してはなりません（MUST NOT）。

たとえば、次を含むレスポンス：

Vary: accept-encoding, accept-language

は、オリジンサーバーがこのレスポンスのコンテンツを選択する際の決定要因として、リクエストのAccept-EncodingおよびAccept-Languageヘッダフィールド（またはそれらの欠如）を使用した可能性があることを示します。

フィールド名のリストを含むVaryフィールドには、2つの目的があります：

  1. 後続のリクエストがリストされたヘッダフィールドに対して元のリクエストと同じ値を持たない限り、またはレスポンスの再利用がオリジンサーバーによって検証されていない限り、キャッシュ受信者にこのレスポンスを後続のリクエストを満たすために使用してはならない（MUST NOT）ことを通知します（[CACHING]のセクション4.1を参照）。つまり、Varyは、新しいリクエストを保存されたキャッシュエントリに一致させるために必要なキャッシュキーを拡張します。

  2. このレスポンスがコンテンツネゴシエーションの対象であったこと（セクション12）、およびリストされたヘッダフィールドに追加の値が提供されると、後続のリクエストで異なる表現が送信される可能性があることをユーザーエージェント受信者に通知します（プロアクティブネゴシエーション）。

オリジンサーバーは、そのリソースへの後続のリクエストに対してレスポンスを選択的に再利用したい場合、キャッシュ可能なレスポンスでVaryヘッダフィールドを生成すべきです（SHOULD）。通常、これは、リクエストのAccept-Languageヘッダフィールドに基づいてレスポンスの言語を選択した場合など、レスポンスコンテンツがこれらの選択ヘッダフィールドで表現された設定により適合するようにカスタマイズされた場合です。

オリジンサーバーが、コンテンツ選択の変化がキャッシュに対するVaryのパフォーマンスへの影響ほど重要ではないと考える場合、特に再利用がすでにキャッシュレスポンス指令によって制限されている場合（[CACHING]のセクション5.2を参照）、Varyを省略できます。

Authorizationフィールド名をVaryで送信する必要はありません。なぜなら、フィールド定義は異なるユーザーに対するそのレスポンスの再利用を禁止しているためです（セクション11.6.2）。同様に、レスポンスコンテンツがネットワーク地域によって選択または影響を受けたが、オリジンサーバーが受信者がある地域から別の地域に移動した場合でもキャッシュされたレスポンスを再利用したい場合、オリジンサーバーはVaryでその変化を示す必要はありません。

に最終更新