3. Representations (表現)

リソースは何でもあり得ることを考慮すると、HTTPが提供する統一インターフェースは、反対側の独立したアクターとのメッセージ通信を通じてのみ、そのようなものを観察し作用できる窓に似ています。したがって、通信における当該物の現在または望ましい状態を「表現する」（「代わりをする」）抽象化が必要です。この抽象化は表現 (representation) と呼ばれます [REST]。

HTTPの目的において、「表現」(representation) とは、特定のリソースの過去、現在、または望ましい状態を反映することを意図した情報であり、プロトコルを介して容易に通信できる形式で、一連の表現メタデータと潜在的に無制限の表現データストリームで構成されます。

オリジンサーバー (origin server) には、ターゲットリソースの現在の状態を反映することを意図した複数の表現が提供されるか、生成できる可能性があります。そのような場合、オリジンサーバーは何らかのアルゴリズムを使用して、これらの表現の中から特定のリクエストに最も適用可能なものを選択します。通常、コンテンツネゴシエーション (content negotiation) に基づいて選択されます。この「選択された表現」(selected representation) は、条件付きリクエスト [RFC7232] を評価し、GET [Section 4.3.1] への200 (OK) および304 (Not Modified) レスポンスのペイロードを構築するためのデータとメタデータを提供するために使用されます。

3.1. Representation Metadata (表現メタデータ)

表現ヘッダーフィールド (representation header fields) は、表現に関するメタデータを提供します。メッセージにペイロードボディ (payload body) が含まれている場合、表現ヘッダーフィールドは、ペイロードボディに封入された表現データを解釈する方法を記述します。HEADリクエストへのレスポンスでは、表現ヘッダーフィールドは、同じリクエストがGETであった場合にペイロードボディに封入されていたであろう表現データを記述します。

3.1.1. Processing Representation Data (表現データの処理)

表現メタデータの目的は、受信者が取り扱っている形式、表現が使用する言語、および介在する仲介者によって表現データに適用された変換を知ることを可能にすることです。

3.1.1.1. Media Type (メディアタイプ)

HTTPは、Content-Type (Section 3.1.1.5) および Accept (Section 5.3.2) ヘッダーフィールドでインターネットメディアタイプ [RFC2046] を使用して、オープンで拡張可能なデータタイピングとタイプネゴシエーションを提供します。メディアタイプは、データ形式とさまざまな処理モデルの両方を定義します：受信される各コンテキストに従ってそのデータを処理する方法。

media-type = type "/" subtype *( OWS ";" OWS parameter )
type       = token
subtype    = token

タイプ/サブタイプの後には、名前=値のペアの形式でパラメータを続けることができます。

parameter      = token "=" ( token / quoted-string )

タイプ、サブタイプ、およびパラメータ名のトークンは大文字小文字を区別しません。パラメータ値は、パラメータ名のセマンティクスに応じて、大文字小文字を区別する場合と区別しない場合があります。パラメータの存在または不在は、メディアタイプレジストリ内のその定義に応じて、メディアタイプの処理にとって重要である可能性があります。

トークン生成規則に一致するパラメータ値は、トークンとして、または引用符で囲まれた文字列内で送信できます。引用符で囲まれた値と囲まれていない値は同等です。たとえば、次の例はすべて同等ですが、一貫性のために最初のものが推奨されます：

text/html;charset=utf-8
text/html;charset=UTF-8
text/HTML;charset="utf-8"
text/html; charset="utf-8"

インターネットメディアタイプは、[BCP13] で定義された手順に従ってIANAに登録する必要があります。

3.1.1.2. Charset (文字セット)

HTTPは、文字セット名を使用して、テキスト表現の文字エンコーディングスキーム [RFC6365] を示したり、ネゴシエートしたりします。文字セットは、大文字小文字を区別しないトークンによって識別されます。

charset = token

文字セット名は、[RFC2978] で定義された手順に従って、IANA「文字セット」レジストリ (http://www.iana.org/assignments/character-sets) に登録する必要があります。

3.1.1.3. Canonicalization and Text Defaults (正規化とテキストのデフォルト)

インターネットメディアタイプは、さまざまなネイティブエンコーディング形式を持つシステム間で相互運用可能にするために、正規形式で登録されます。HTTPを介して選択または転送される表現は、多目的インターネットメール拡張 (Multipurpose Internet Mail Extensions, MIME) [RFC2045] で説明されているのとほぼ同じ理由で、正規形式であるべきです。ただし、電子メール展開のパフォーマンス特性（すなわち、ピアへのメッセージの保存と転送）は、HTTPとWebに共通するもの（サーバーベースの情報サービス）とは大きく異なります。さらに、古いメール転送プロトコルとの互換性のためのMIMEの制約は、HTTPには適用されません（付録Aを参照）。

MIMEの正規形式では、「text」タイプのメディアサブタイプがCRLFをテキスト改行として使用することが要求されます。HTTPでは、そのような改行が表現全体で一貫している場合、プレーンCRまたはLFのみで改行を表すテキストメディアの転送が許可されます。HTTP送信者は生成してもよく (MAY)、受信者は解析できなければなりません (MUST)。CRLF、ベアCR、またはベアLFで構成されるテキストメディアの改行。さらに、HTTPのテキストメディアは、CRとLFにそれぞれオクテット13と10を使用する文字セットに限定されません。改行に関するこの柔軟性は、「text」メディアタイプが割り当てられた表現内のテキストにのみ適用されます。「multipart」タイプやペイロードボディ外のHTTP要素（例：ヘッダーフィールド）には適用されません。

表現がコンテンツコーディング (content-coding) でエンコードされている場合、基礎となるデータは、エンコードされる前に上記で定義された形式であるべきです。

3.1.1.4. Multipart Types (マルチパートタイプ)

MIMEは、単一のメッセージボディ内の1つ以上の表現のカプセル化である、多数の「multipart」タイプを提供します。すべてのマルチパートタイプは、[RFC2046] のSection 5.1.1で定義されている共通の構文を共有し、メディアタイプ値の一部として境界パラメータを含みます。メッセージボディ自体はプロトコル要素です。送信者は、ボディパート間の改行を表すためにCRLFのみを生成しなければなりません (MUST)。

HTTPメッセージフレーミングは、メッセージボディ長のインジケーターとしてマルチパート境界を使用しませんが、ペイロードを生成または処理する実装によって使用される可能性があります。たとえば、「multipart/byteranges」タイプは、一部の206 (Partial Content) レスポンス [RFC7233] で使用するためにHTTPによって定義されています。

3.1.1.5. Content-Type (コンテンツタイプ)

Content-Type ヘッダーフィールドは、関連する表現のメディアタイプを示します：メッセージペイロードに封入された表現、または選択された表現のいずれか（メッセージセマンティクスによって決定されます）。示されたメディアタイプは、データ形式と、Content-Encodingによって示されるコンテンツコーディングがデコードされた後、受信されたメッセージセマンティクスの範囲内で、受信者がそのデータをどのように処理することを意図しているかの両方を定義します。

Content-Type = media-type

メディアタイプはSection 3.1.1.1で定義されています。フィールドの例は次のとおりです：

Content-Type: text/html; charset=ISO-8859-4

ペイロードボディを含むメッセージを生成する送信者は、封入された表現の意図されたメディアタイプが送信者に不明でない限り、そのメッセージに Content-Type ヘッダーフィールドを生成すべきです (SHOULD)。Content-Type ヘッダーフィールドが存在しない場合、受信者は「application/octet-stream」([RFC2046] Section 4.5.1) のメディアタイプを仮定するか、データを検査してそのタイプを判断してもよい (MAY) です。

実際には、リソース所有者は、特定の表現に対して正しい Content-Type を提供するようにオリジンサーバーを常に適切に構成しているわけではなく、その結果、一部のクライアントはペイロードのコンテンツを検査し、指定されたタイプを上書きします。そうするクライアントは、誤った結論を導くリスクがあり、追加のセキュリティリスク（例：「特権昇格」）にさらされる可能性があります。さらに、データ形式を検査することによって送信者の意図を判断することは不可能です：多くのデータ形式は、処理セマンティクスのみが異なる複数のメディアタイプに一致します。実装者は、使用時にそのような「コンテンツスニッフィング」(content sniffing) を無効にする手段を提供することが推奨されます。

3.1.2. Encoding for Compression or Integrity (圧縮または完全性のためのエンコーディング)

3.1.2.1. Content Codings (コンテンツコーディング)

コンテンツコーディング値 (content coding values) は、表現に適用されている、または適用できるエンコーディング変換を示します。コンテンツコーディングは主に、基礎となるメディアタイプのアイデンティティを失うことなく、情報を失うことなく、表現を圧縮したり、他の有用な方法で変換したりできるようにするために使用されます。通常、表現はコード化された形式で保存され、直接送信され、受信者のみがデコードします。

content-coding   = token

すべてのコンテンツコーディング値は大文字小文字を区別せず、Section 8.4で定義されている「HTTPコンテンツコーディングレジストリ」(HTTP Content Coding Registry) に登録する必要があります。これらは、Accept-Encoding (Section 5.3.4) および Content-Encoding (Section 3.1.2.2) ヘッダーフィールドで使用されます。

本仕様では、以下のコンテンツコーディング値が定義されています：

• compress (および x-compress)：UNIX「compress」データ形式 [Welch]。歴史的なもの。新しいアプリケーションでの使用は推奨されません。

• deflate：「zlib」形式 [RFC1950] と「deflate」圧縮メカニズム [RFC1951] の組み合わせ。

• gzip (および x-gzip)：32ビットCRCを使用したLZ77コーディング [RFC1952]。

• identity：「identity」コーディング（変換なし）。このコーディングはAccept-Encodingヘッダーフィールドでのみ使用され、Content-Encoding ヘッダーフィールドでは使用すべきではありません (SHOULD NOT)。

3.1.2.2. Content-Encoding (コンテンツエンコーディング)

Content-Encoding ヘッダーフィールドは、メディアタイプに固有のエンコーディングを超えて、表現に適用されたコンテンツコーディングを示します。したがって、Content-Type ヘッダーフィールドで参照されているメディアタイプのデータを取得するために適用する必要があるデコーディングメカニズムを示します。Content-Encoding は主に、基礎となるメディアタイプのアイデンティティを失うことなく、表現のデータを圧縮できるようにするために使用されます。

Content-Encoding = 1#content-coding

使用例は次のとおりです：

Content-Encoding: gzip

1つ以上のエンコーディングが表現に適用されている場合、エンコーディングを適用した送信者は、適用された順序でコンテンツコーディングをリストする Content-Encoding ヘッダーフィールドを生成しなければなりません (MUST)。エンコーディングパラメータに関する追加情報は、本仕様で定義されていない他のヘッダーフィールドによって提供できます。

Transfer-Encoding (Section 3.3 of [RFC7230]) とは異なり、Content-Encoding にリストされているコーディングは表現の特性です。表現はコード化された形式で定義され、表現に関する他のすべてのメタデータは、メタデータ定義で別途記載されていない限り、コード化された形式に関するものです。通常、表現はレンダリングまたは類似の使用の直前にのみデコードされます。

メディアタイプに、常に圧縮されているデータ形式などの固有のエンコーディングが含まれている場合、そのエンコーディングがコンテンツコーディングの1つと同じアルゴリズムであっても、Content-Encoding で再記述されることはありません。そのようなコンテンツコーディングは、何らかの奇妙な理由で表現を形成するために2回目に適用される場合にのみリストされます。同様に、オリジンサーバーは、一部のユーザーエージェントが各レスポンスの処理で異なる動作をするため（例：コンテンツの自動解凍とレンダリングではなく「名前を付けて保存...」ダイアログを開く）、コーディングが Content-Type の一部として定義されているか Content-Encoding の一部として定義されているかだけが異なる複数の表現として同じデータを公開することを選択する場合があります。

リクエストメッセージの表現に受け入れられないコンテンツコーディングがある場合、オリジンサーバーは415 (Unsupported Media Type) のステータスコードで応答してもよい (MAY) です。

3.1.3. Audience Language (オーディエンス言語)

3.1.3.1. Language Tags (言語タグ)

言語タグ (language tag) は、[RFC5646] で定義されているように、人間が他の人間に情報を伝達するために話す、書く、またはその他の方法で伝達する自然言語を識別します。コンピュータ言語は明示的に除外されています。

HTTPは、Accept-Language および Content-Language ヘッダーフィールド内で言語タグを使用します。Accept-Language はSection 5.3.5で定義されているより広範なlanguage-range生成規則を使用し、Content-Language は以下で定義されているlanguage-tag生成規則を使用します。

language-tag = <Language-Tag, see [RFC5646], Section 2.1>

言語タグは、1つ以上の大文字小文字を区別しないサブタグのシーケンスであり、各サブタグはハイフン文字（「-」、%x2D）で区切られています。ほとんどの場合、言語タグは、関連言語の広範なファミリーを識別する主要言語サブタグ（例：「en」= 英語）で構成され、その後にオプションでその言語の範囲を絞り込むまたは狭めるサブタグのシリーズが続きます（例：「en-CA」= カナダで使用される英語の変種）。言語タグ内では空白は許可されません。タグの例には次のものがあります：

en, en-US, en-cockney, i-cherokee, x-pig-latin

詳細については [RFC5646] を参照してください。

3.1.3.2. Content-Language (コンテンツ言語)

Content-Language ヘッダーフィールドは、表現の対象オーディエンスの自然言語を記述します。これは、表現内で使用されるすべての言語と同等ではない可能性があることに注意してください。

Content-Language = 1#language-tag

言語タグはSection 3.1.3.1で定義されています。Content-Language の主な目的は、ユーザーが自分の好みの言語に従って表現を識別および区別できるようにすることです。したがって、コンテンツがデンマーク語を理解するオーディエンスのみを対象としている場合、適切なフィールドは次のとおりです：

Content-Language: da

Content-Language が指定されていない場合、デフォルトでは、コンテンツはすべての言語オーディエンスを対象としています。これは、送信者がそれを特定の自然言語に固有とは見なしていないか、送信者がどの言語を対象としているかを知らないことを意味する場合があります。

複数のオーディエンスを対象としたコンテンツには、複数の言語をリストしてもよい (MAY) です。たとえば、元のマオリ語版と英語版で同時に提示される「ワイタンギ条約」(Treaty of Waitangi) の演出では、次のように呼び出します：

Content-Language: mi, en

ただし、表現内に複数の言語が存在するからといって、それが複数の言語オーディエンスを対象としているわけではありません。例としては、「ラテン語の最初のレッスン」(A First Lesson in Latin) のような初心者向け言語入門書があり、これは明らかに英語を理解するオーディエンスが使用することを意図しています。この場合、Content-Language は適切に「en」のみを含むべきです。

Content-Language は任意のメディアタイプに適用してもよい (MAY) です。テキストドキュメントに限定されません。

3.1.4. Identification (識別)

3.1.4.1. Identifying a Representation (表現の識別)

完全または部分的な表現がメッセージペイロードで転送される場合、送信者がその表現に対応するリソースの識別子を提供したり、受信者が決定したりすることが望ましい場合がよくあります。

リクエストメッセージの場合：

• リクエストに Content-Location ヘッダーフィールドがある場合、送信者は、ペイロードが Content-Location フィールド値によって識別されるリソースの表現であると主張します。ただし、そのような主張は、他の手段（本仕様では定義されていない）で検証できない限り、信頼できません。情報は、リビジョン履歴リンクに対してまだ有用である可能性があります。

• それ以外の場合、ペイロードは識別されていません。

レスポンスメッセージの場合、一致が見つかるまで、次の規則が順番に適用されます：

1. リクエストメソッドがGETまたはHEADであり、レスポンスステータスコードが200 (OK)、204 (No Content)、206 (Partial Content)、または304 (Not Modified) である場合、ペイロードは有効リクエストURI (Section 5.5 of [RFC7230]) によって識別されるリソースの表現です。

2. リクエストメソッドがGETまたはHEADであり、レスポンスステータスコードが203 (Non-Authoritative Information) である場合、ペイロードは仲介者によって提供されるターゲットリソースの潜在的に変更または拡張された表現です。

3. レスポンスに Content-Location ヘッダーフィールドがあり、そのフィールド値が有効リクエストURIと同じURIへの参照である場合、ペイロードは有効リクエストURIによって識別されるリソースの表現です。

4. レスポンスに Content-Location ヘッダーフィールドがあり、そのフィールド値が有効リクエストURIとは異なるURIへの参照である場合、送信者は、ペイロードが Content-Location フィールド値によって識別されるリソースの表現であると主張します。ただし、そのような主張は、他の手段（本仕様では定義されていない）で検証できない限り、信頼できません。

5. それ以外の場合、ペイロードは識別されていません。

3.1.4.2. Content-Location (コンテンツロケーション)

Content-Location ヘッダーフィールドは、このメッセージのペイロード内の表現に対応する特定のリソースの識別子として使用できるURIを参照します。言い換えれば、このメッセージの生成時にこのURIに対してGETリクエストを実行すると、200 (OK) レスポンスには、このメッセージにペイロードとして封入されているものと同じ表現が含まれます。

Content-Location = absolute-URI / partial-URI

Content-Location 値は、有効リクエストURI (Section 5.5 of [RFC7230]) の置き換えではありません。それは表現メタデータです。これは、[RFC2557] のSection 4でMIMEボディパート用に定義されている同名のヘッダーフィールドと同じ構文とセマンティクスを持っています。ただし、HTTPメッセージでの出現は、HTTP受信者にとっていくつかの特別な意味を持ちます。

Content-Location が2xx (Successful) レスポンスメッセージに含まれ、その値が（絶対形式に変換された後）有効リクエストURIと同じURIを参照している場合、受信者は、ペイロードをメッセージ発信日で示される時刻のそのリソースの現在の表現と見なしてもよい (MAY) です。GET (Section 4.3.1) またはHEAD (Section 4.3.2) リクエストの場合、これは、サーバーが Content-Location を提供しない場合のデフォルトのセマンティクスと同じです。PUT (Section 4.3.4) またはPOST (Section 4.3.3) などの状態変更リクエストの場合、これは、サーバーのレスポンスにそのリソースの新しい表現が含まれていることを意味し、アクションのみを報告する可能性のある表現（例：「成功しました！」）と区別します。これにより、オーサリングアプリケーションは、後続のGETリクエストを必要とせずにローカルコピーを更新できます。

Content-Location が2xx (Successful) レスポンスメッセージに含まれ、そのフィールド値が有効リクエストURIとは異なるURIを参照している場合、オリジンサーバーは、URIが封入された表現に対応する異なるリソースの識別子であると主張します。そのような主張は、両方の識別子が同じリソース所有者を共有している場合にのみ信頼できますが、これはHTTPを介してプログラムで判断することはできません。

• GETまたはHEADリクエストへのレスポンスの場合、これは、有効リクエストURIがコンテンツネゴシエーションの対象となるリソースを参照しており、Content-Location フィールド値が選択された表現のより具体的な識別子であることを示します。

• POSTリクエストへの201 (Created) レスポンスの場合、Content-Location フィールド値は、送信されたデータに対応するリソース（つまり、有効リクエストURIによって識別されるリソースとは異なるリソース）への参照です。

• それ以外の場合、そのような Content-Location は、このペイロードがリクエストメッセージのターゲット以外の何らかのリソースの表現であることを示し、HTTPに対して他の意味はありません。

Content-Location がレスポンスメッセージに含まれ、表現が複数のパートで構成されている場合（「multipart/*」の Content-Type で示されている）、各パートは、そのパートに対応するリソースを示す独自の Content-Location を持ってもよい (MAY) です。それ以外の場合、Content-Location はペイロード全体にのみ適用されます。

3.2. Representation Data (表現データ)

HTTPメッセージに関連付けられた表現データは、メッセージのペイロードボディとして提供されるか、メッセージセマンティクスと有効リクエストURIによって参照されます。表現データは、表現メタデータヘッダーフィールドによって定義された形式とエンコーディングです。

表現データのデータタイプは、ヘッダーフィールド Content-Type および Content-Encoding を介して決定されます。これらは、2層の順序付けられたエンコーディングモデルを定義します：

representation-data := Content-Encoding( Content-Type( bits ) )

3.3. Payload Semantics (ペイロードセマンティクス)

一部のHTTPメッセージは、メッセージ「ペイロード」(payload) として完全または部分的な表現を転送します。場合によっては、ペイロードには、関連する表現のヘッダーフィールドのみ（例：HEADへのレスポンス）または表現データの一部のみ（例：206 (Partial Content) ステータスコード）が含まれる場合があります。

リクエスト内のペイロードの目的は、メソッドセマンティクスによって定義されます。たとえば、PUTリクエスト (Section 4.3.4) のペイロード内の表現は、リクエストが正常に適用された場合のターゲットリソースの望ましい状態を表しますが、POSTリクエスト (Section 4.3.3) のペイロード内の表現は、ターゲットリソースによって処理される情報を表します。

レスポンスでは、ペイロードの目的は、リクエストメソッドとレスポンスステータスコードの両方によって定義されます。たとえば、GET (Section 4.3.1) への200 (OK) レスポンスのペイロードは、メッセージ発信日 (Section 7.1.1.2) に観察されたターゲットリソースの現在の状態を表しますが、POSTへの同じステータスコードのレスポンスのペイロードは、処理結果または処理を適用した後のターゲットリソースの新しい状態のいずれかを表す場合があります。

ペイロードは、次の場合に「完全」(complete) と見なされます：

• ヘッダーセクション全体が受信され、示されたペイロードボディ長がゼロである。

• チャンク化されたペイロード (chunked payload) は、チャンク化されたボディパートが完了したときに完了します（ゼロ長チャンクと終端CRLFで示されます）。

• 不明なペイロード長は、接続が閉じられたときに完了します。

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

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

本仕様では、プロトコル内で可視化できる3つのコンテンツネゴシエーションパターンを定義します：「プロアクティブ」(proactive)（サーバーがユーザーエージェントの表明された好みに基づいて表現を選択する）、「リアクティブ」(reactive)（サーバーがユーザーエージェントが選択するための表現のリストを提供する）、および「リクエストコンテンツ」(request content)（ユーザーエージェントがリクエストペイロードの表現を選択する）。コンテンツネゴシエーションの他のパターンには、「条件付きコンテンツ」(conditional content)（表現が複数のパートで構成され、ユーザーエージェントパラメータに基づいて選択的にレンダリングされる）、「アクティブコンテンツ」(active content)（表現にユーザーエージェントの特性に基づいて追加の（より具体的な）リクエストを行うスクリプトが含まれる）、および「透明コンテンツネゴシエーション」(Transparent Content Negotiation) ([RFC2295])（コンテンツ選択が仲介者によって実行される）が含まれます。これらのパターンは相互に排他的ではなく、それぞれに適用性と実用性のトレードオフがあります。

すべての場合において、HTTPはリソースセマンティクスを認識していないことに注意してください。オリジンサーバーが時間の経過とコンテンツネゴシエーションのさまざまな次元にわたってリクエストに応答する一貫性、したがって時間の経過に伴うリソースの観察された表現の「同一性」は、それらのレスポンスを選択または生成するエンティティまたはアルゴリズムによって完全に決定されます。HTTPは裏側の人間に注意を払いません。

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

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

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

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

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

• すべてのリクエストでユーザーエージェントにその能力を記述させることは、非常に非効率的（複数の表現を持つレスポンスはごくわずかなパーセンテージであることを考えると）であり、ユーザーのプライバシーに対する潜在的なリスクでもある可能性があります。

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

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

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

Varyヘッダーフィールド (Section 7.1.4) は、選択アルゴリズムで使用されたリクエスト情報のどの部分を示すために、プロアクティブネゴシエーションの対象となるレスポンスでよく送信されます。

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

リアクティブネゴシエーション (reactive negotiation)（別名、エージェント駆動ネゴシエーション）では、最良のレスポンス表現の選択（ステータスコードに関係なく）は、代替表現のリソースのリストを含むオリジンサーバーからの初期レスポンスを受信した後、ユーザーエージェントによって実行されます。ユーザーエージェントが初期レスポンス表現に満足していない場合、リストに含まれるメタデータに基づいて選択された1つ以上の代替リソースに対してGETリクエストを実行して、そのレスポンスの異なる形式の表現を取得できます。代替案の選択は、ユーザーエージェントによって自動的に実行されるか、生成された（おそらくハイパーテキスト）メニューからユーザーが手動で選択する場合があります。

上記は、一般的にレスポンスの表現を指しており、リソースの表現を指しているわけではないことに注意してください。代替表現は、必ずしも同じリソースの表現ではありませんが、そうである可能性があります。

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

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

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

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

コンテンツネゴシエーション設定がサーバーのクライアントへのレスポンスで送信される場合、クライアントはそれらの設定を使用して、そのリソースへの後続のリクエストに最適な表現を決定できます。これはリクエストコンテンツネゴシエーション (request content negotiation)（別名、「サービス品質としてのコンテンツネゴシエーション」）と呼ばれます。

たとえば、415 (Unsupported Media Type) レスポンスの Accept ヘッダーフィールドは、そのリソースへのPUTリクエストでどのメディアタイプが受け入れられるかを示す場合があり、レスポンスの Accept-Language フィールドはサービスの言語設定を示す場合があります。

---