From 8ba6dbd17b16f00663b2fa0a588c6b41706f8d2a Mon Sep 17 00:00:00 2001 From: Masahiro FUJIMOTO Date: Mon, 31 Jan 2022 23:50:04 +0900 Subject: 2021/11/03 時点の英語版に同期 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- files/ja/web/http/content_negotiation/httpnego.png | Bin 0 -> 11623 bytes .../ja/web/http/content_negotiation/httpnego3.png | Bin 0 -> 26143 bytes .../http/content_negotiation/httpnegoserver.png | Bin 0 -> 15155 bytes files/ja/web/http/content_negotiation/index.md | 155 ++++++++------------- 4 files changed, 59 insertions(+), 96 deletions(-) create mode 100644 files/ja/web/http/content_negotiation/httpnego.png create mode 100644 files/ja/web/http/content_negotiation/httpnego3.png create mode 100644 files/ja/web/http/content_negotiation/httpnegoserver.png (limited to 'files/ja/web') diff --git a/files/ja/web/http/content_negotiation/httpnego.png b/files/ja/web/http/content_negotiation/httpnego.png new file mode 100644 index 0000000000..3b8cdf6261 Binary files /dev/null and b/files/ja/web/http/content_negotiation/httpnego.png differ diff --git a/files/ja/web/http/content_negotiation/httpnego3.png b/files/ja/web/http/content_negotiation/httpnego3.png new file mode 100644 index 0000000000..d0202ac28a Binary files /dev/null and b/files/ja/web/http/content_negotiation/httpnego3.png differ diff --git a/files/ja/web/http/content_negotiation/httpnegoserver.png b/files/ja/web/http/content_negotiation/httpnegoserver.png new file mode 100644 index 0000000000..443057e875 Binary files /dev/null and b/files/ja/web/http/content_negotiation/httpnegoserver.png differ diff --git a/files/ja/web/http/content_negotiation/index.md b/files/ja/web/http/content_negotiation/index.md index ba1f19270e..8a4c43eac2 100644 --- a/files/ja/web/http/content_negotiation/index.md +++ b/files/ja/web/http/content_negotiation/index.md @@ -1,147 +1,110 @@ --- -title: コンテントネゴシエーション +title: コンテンツ交渉 slug: Web/HTTP/Content_negotiation tags: - - Content Negotiation - - Content Negotiation Reference + - コンテンツ交渉 + - コンテンツ交渉リファレンス - HTTP - - Reference - - コンテントネゴシエーション + - リファレンス + - コンテンツ交渉 translation_of: Web/HTTP/Content_negotiation --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

HTTP においてコンテントネゴシエーション (content negotiation) は、同じ URL におけるさまざまな表現のリソースを提供するために使用する仕組みであり、ユーザーエージェントはどのリソースがユーザーにもっとも適しているか (例えばどの文書の言語か、どの画像形式か、どのコンテンツエンコード方式か) を指定することができます。

+[HTTP](/ja/docs/Glossary/HTTP) において**コンテンツ交渉** (content negotiation) は、同じ URI におけるさまざまな{{Glossary("Representation header","表現")}}のリソースを提供するために使用する仕組みであり、ユーザーエージェントはどのリソースがユーザーにもっとも適しているか (例えば文書の言語はどれか、画像形式はどれか、コンテンツエンコード方式はどれか) を指定することができます。 -

コンテントネゴシエーションの原理

+> **Note:** [WHATWG のウィキページ](https://wiki.whatwg.org/wiki/Why_not_conneg)には、 HTTP コンテンツ交渉の短所がいくつか書かれています。 HTML5 では、コンテンツ交渉の代替として、例えば [`` 要素](/ja/docs/Web/HTML/Element/source)を提供しています。 -

特定の文書はリソース (resource) と呼ばれます。クライアントがリソースを取得したいときは、 URL を使用してリクエストします。サーバーはこの URL を、提供するものを複数の変化形からひとつ選択するために使用し – それぞれの変化形は表現 (representation) と呼ばれます – 特定の表現をクライアントに返します。それぞれの表現を含むリソース全体が一つの特定の URL を持ちます。リソースが呼び出されたときに特定の表現を選択する方法はコンテントネゴシエーションによって決められ、クライアントサーバーの間で交渉する方法がいくつかあります。

+### コンテンツ交渉の原理 -

+特定の文書は**リソース** (_resource_) と呼ばれます。クライアントがリソースを取得したいときは、 URL でリクエストします。サーバーはこの URL **表現** (_representation_) と呼ばれます–特定の表現をクライアントに返します。それぞれの表現を含むリソース全体が一つの特定の URL を持ちます。**コンテンツ交渉**は、リソースが呼び出されたときに特定の表現を選択する方法を定めます。クライアントサーバーの間で交渉する方法がいくつかあります。 -

最適な表現の決定は、以下の 2 つの仕組みのいずれかによって行われます。

+![](httpnego.png) - +最適な表現は、以下の 2 つの仕組みのいずれかによって識別されます。 -

数年来、透過的コンテントネゴシエーション (transparent content negotiation) や Alternates ヘッダーといった他のコンテントネゴシエーションが提案されてきました。これらは支持を得られず、破棄されました。

+- クライアントによる特定の [HTTP ヘッダー](/ja/docs/Web/HTTP/Headers) (**サーバー駆動型交渉**または **プロアクティブ交渉**)。これは、特定の種類のリソースで交渉を行う標準的な方法です。 +- サーバーによる {{HTTPStatus("300")}} (Multiple Choices) または {{HTTPStatus("406")}} (Not Acceptable) [HTTP レスポンスコード](/ja/docs/Web/HTTP/Status) (**エージェント駆動型交渉** または **リアクティブ交渉**)。これはフォールバック機構として使用します。 -

サーバー駆動型コンテントネゴシエーション

+数年来、[透過的コンテンツ交渉 (transparent content negotiation)](https://datatracker.ietf.org/doc/html/rfc2295) や `Alternates` ヘッダーといった他のコンテンツ交渉が提案されてきました。これらは支持を得られず、破棄されました。 -

サーバー駆動型コンテントネゴシエーション またはプロアクティブコンテントネゴシエーションでは、ブラウザー (または他のユーザーエージェント) が URI と共にいくつかの HTTP ヘッダーを送信します。これらのヘッダーは、ユーザーにとって好ましいものを表します。サーバーではそれらを手がかりとして使用して内部アルゴリズムが、クライアントに提供する最善のコンテンツを選択します。そのアルゴリズムはサーバーによって異なり、標準化されていません。例として、Apache ネゴシエーションアルゴリズム をご覧ください。

+## サーバー駆動型コンテンツ交渉 -

+**サーバー駆動型コンテンツ交渉**またはプロアクティブコンテンツ交渉では、ブラウザー（または他の種類のユーザー エージェント）はいくつかの HTTP ヘッダーを URL と一緒に送信します。これらのヘッダーには、ユーザーが希望する選択肢を記述します。サーバーはこれらをヒントとして使い、内部アルゴリズムがクライアントに提供する最適なコンテンツを選択します。適切なリソースを提供できない場合、 {{HTTPStatus("406")}} (Not Acceptable) または {{HTTPStatus("415")}} (Unsupported Media Type) で応答し、対応しているメディアタイプのヘッダーを設定します（たとえば、POST と PATCH リクエストに対しては、それぞれ {{HTTPHeader("Accept-Post")}} または {{HTTPHeader("Accept-Patch")}} を使用します）。このアルゴリズムはサーバーに依存し、標準では定義されていません。 [Apache の交渉アルゴリズム](https://httpd.apache.org/docs/current/ja/content-negotiation.html#algorithm) をご覧ください。 -

HTTP/1.1 標準では、サーバー駆動型ネゴシエーションを開始する標準ヘッダーの一覧 ({{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Language")}}) を定義しています。厳密に言えば {{HTTPHeader("User-Agent")}} はこの一覧に含まれていませんが、要求したリソースの特定の表現を送信するために使用されることがあります。ただし、これはよい慣習ではないと考えられています。サーバーはどのヘッダーを実際にコンテントネゴシエーションで使用したかを示すために {{HTTPHeader("Vary")}} ヘッダー (あるいは、より的確な関係があるレスポンスヘッダー) を使用します。これにより、キャッシュ が適切に機能します。

+![](httpnegoserver.png) -

さらに、ネゴシエーションに使用できるヘッダーを追加する実験的な提案があり、client hints と呼ばれています。 client hints は、ユーザーエージェントを実行しているデバイスがどのようなものか (例えば、デスクトップコンピューターかモバイル端末か) を伝えます。

+HTTP/1.1 標準では、サーバー駆動型交渉を開始する標準ヘッダーの一覧 (例えば {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Language")}}) を定義しています。厳密に言えば {{HTTPHeader("User-Agent")}} はこの一覧に含まれていませんが、リクエストしたリソースの特定の表現を送信するために使用されることがあります。ただし、これはよい習慣ではないと考えられています。サーバーはどのヘッダーを実際にコンテンツ交渉で使用したかを示すために {{HTTPHeader("Vary")}} ヘッダー（あるいは、より的確な関係があるレスポンスヘッダー）を使用します。これにより、[キャッシュ](/ja/docs/Web/HTTP/Caching)が適切に機能します。 -

サーバー駆動型コンテントネゴシエーションはリソースの特定の表現を決定するためのもっとも一般的な方法ですが、いくつか欠点があります:

+さらに、交渉に使用できるヘッダーを追加する実験的な提案があり、**クライアントヒント**と呼ばれています。クライアントヒントは、ユーザーエージェントを実行しているデバイスがどのようなものか（例えば、デスクトップコンピューターかモバイル端末か）を伝えます。 - +サーバー駆動型コンテンツ交渉は、リソースの特定の表現を決定するためのもっとも一般的な方法ですが、いくつか欠点があります。 -

Accept ヘッダー

+- サーバーは、ブラウザーのことをすべて知っているわけではありません。クライアント拡張を加えても、ブラウザーの機能を完全には把握できません。クライアントが選択するリアクティブコンテンツ交渉とは異なり、サーバーの選択は常に少し独断的です。 +- クライアントが提供する情報はかなり冗長であり（HTTP/2 のヘッダー圧縮は、この問題を緩和します）、またプライバシーのリスク（HTTP フィンガープリンティング）もあります。 +- 指定されたリソースの複数の表現を送信すると、共有キャッシュの効率が下がります。また、サーバーの実装がより複雑になります。 -

{{HTTPHeader("Accept")}} ヘッダーは、エージェントが処理することを望むメディアリソースの MIME タイプを羅列します。これはカンマ区切りで MIME タイプで並べており、それぞれの MIME タイプは、別の MIME タイプとの相対的な優先度を示すパラメータであるクオリティファクターと結びつけられています。

+### `Accept` ヘッダー -

{{HTTPHeader("Accept")}} ヘッダーはブラウザーまたは他のユーザーエージェントによって定義され、それは HTML ページ・画像・動画・スクリプトなど取得するものによって変わる場合があります。アドレスバーで指定したドキュメントを取得するときと {{ HTMLElement("img") }}, {{ HTMLElement("video") }}, {{ HTMLElement("audio") }} 要素でリンクしたものを取得するときで、このヘッダーは異なります。ブラウザーはこのヘッダーで、最適と思われる値を自由に使用できます。一般的なブラウザーの既定値 の包括的な一覧があります。

+{{HTTPHeader("Accept")}} ヘッダーは、エージェントが処理することを望むメディアリソースの MIME タイプを羅列します。これはカンマ区切りの MIME タイプのリストで、それぞれの MIME タイプは、別の MIME タイプとの相対的な優先度を示す引数である品質係数と結びつけられています。 -

Accept-CH ヘッダー {{experimental_inline}}

+`Accept` ヘッダーは、ブラウザーまたは他のユーザーエージェントによって定義され、そのコンテキストによって変わることがあります。例えば、取得するものが HTML ページ、画像、動画、スクリプトなどに変わります。アドレスバーで指定した文書を取得するときと {{ HTMLElement("img") }}, {{ HTMLElement("video") }}, {{ HTMLElement("audio") }} 要素でリンクしたものを取得するときで異なります。ブラウザーはこのヘッダーで、最適と思われる値を自由に使用できます。[一般的なブラウザーの既定値](/ja/docs/Web/HTTP/Content_negotiation/List_of_default_Accept_values)の包括的な一覧があります。 -
-

これはクライアントヒント (Client Hints) と呼ばれる実験的な技術の一部であり、現在は Chrome 46 以降が実装しています。 Device-Memory の値は Chrome 61 以降が実装しています。

-
+### `Accept-CH` ヘッダー {{experimental_inline}} -

実験的な {{HTTPHeader("Accept-CH")}} は、サーバーが適切なリソースを選択するために使用できる設定データを羅列します。有効な値は以下のとおりです:

+> **Note:** これは**クライアントヒント (Client Hints)** と呼ばれる**実験的**な技術の一部であり、現在は Chrome 46 以降が実装しています。 Device-Memory の値は Chrome 61 以降が実装しています。 - - - - - - - - - - - - - - - - - - - - - - - - - -
値意味
Device-Memory端末に搭載されている RAM のおおよその量を示します。この値は、2の整数乗を1024で割った近似値です。たとえば、512メガバイトは 0.5 として報告されます。
DPRクライアントのデバイスピクセル比を示します。
Viewport-Widthレイアウトビューポートの幅を CSS ピクセルで示します。
Widthリソースの幅を物理ピクセルで示します (言い換えると、画像の本来の幅です)。
+{{HTTPHeader("Accept-CH")}} は実験的なもので、サーバーが適切なリソースを選択するために使用できる設定データを羅列します。有効な値は以下のとおりです。 -

Accept-Charset ヘッダー

+| 値 | 意味 | +| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `Device-Memory` | 端末に搭載されている RAM のおおよその量を示します。この値は、 2 の整数乗を 1024 で割った近似値です。たとえば、 512 メガバイトは `0.5` として報告されます。 | +| `Viewport-Width` | レイアウトビューポートの幅を CSS ピクセルで示します。 | +| `Width` | リソースの幅を物理ピクセルで示します（言い換えると、画像の本来の幅です）。 | -

{{HTTPHeader("Accept-Charset")}} ヘッダーは、ユーザーエージェントが理解する文字エンコーディングが何かを、サーバーに示します。伝統的に、例えば西ヨーロッパロケールでは ISO-8859-1,utf-8;q=0.7,*;q=0.7 のように、ブラウザーのために各ロケールへさまざまな値を設定していました。

+### `Accept-CH-Lifetime` ヘッダー -

UTF-8 が良好にサポートされるようになり、文字をエンコードする方法として推奨されるようになっています。また、設定に基づくエントロピーを減らしてプライバシーを保護するために、ブラウザーは Accept-Charset ヘッダーを省略するようになっています。 Internet Explorer 8, Safari 5, Opera 11, Firefox 10, Chrome 27 はこのヘッダーの使用を取りやめました。

+> **Note:** これは、**実験的**な**クライアントヒント**と呼ばれる技術の一部であり、 Chrome 61 以降のみで利用できます。 -

Accept-CH-Lifetime ヘッダー

+{{HTTPHeader("Accept-CH-Lifetime")}} ヘッダーは、 `Accept-CH` ヘッダーの `Device-Memory` 値と共に使用され、端末がメモリーの量をサーバーと共有することを許可すべき時間を示します。値はミリ秒単位で与えられ、使用は任意です。 -
-

これは、実験的なクライアントヒントと呼ばれる技術の一部であり、 Chrome 61 以降でしか利用できません。

-
+### `Accept-Encoding` ヘッダー -

{{HTTPHeader("Accept-CH-Lifetime")}} ヘッダーは、 Accept-CH ヘッダーの Device-Memory 値と共に使用され、端末がメモリの量をサーバーと共有することを許可すべき時間を示します。値はミリ秒単位で与えられ、使用は任意です。

+{{HTTPHeader("Accept-Encoding")}} ヘッダーは、コンテンツの受け入れ可能なエンコーディング（対応する圧縮方式）を定義します。この値は、エンコーディングの優先度を示す Q 値のリスト (例: `br, gzip;q=0.8`) です。既定値 `identity` は（ほかに指定されていなければ）優先度が最低です。 -

Accept-Encoding ヘッダー

+HTTP メッセージの圧縮はウェブサイトのパフォーマンスを向上させるためにもっとも有力な手段のひとつであり、転送するデータのサイズを削減して利用可能な帯域を有効活用します。ブラウザーは常にこのヘッダーを送信し、またサーバーはこのヘッダーを受け入れるように設定して、圧縮を行うべきです。 -

{{HTTPHeader("Accept-Encoding")}} ヘッダーは、受け入れ可能な content-encoding (サポートする圧縮方式) を定義します。この値は、エンコーディングの優先度を示す Q 値のリスト (例: br, gzip;q=0.8) です。既定値 identity は (ほかに宣言されていなければ) 優先度が最低です。

+### `Accept-Language` ヘッダー -

HTTP メッセージの圧縮はウェブサイトのパフォーマンスを向上させるためにもっとも有力な手段のひとつであり、転送するデータのサイズを削減して利用可能な帯域を有効活用します。ブラウザーは常にこのヘッダーを送信します。またサーバーはこのヘッダーを受け入れるように設定して、圧縮を行うべきです。

+{{HTTPHeader("Accept-Language")}} ヘッダーは、ユーザーの言語設定を示すために使用します。これは、品質係数を伴う値のリストです（例: `"de, en;q=0.7`"）。既定値はたいてい、ユーザーエージェントのグラフィカルインターフェイスの言語に従いますが、ほとんどのブラウザーでは異なる言語を設定できます。 -

Accept-Language ヘッダー

+[設定に基づくエントロピー](https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy)が高まるため、変更された値はユーザーのフィンガープリントとして使用される可能性があります。値を変更することは推奨されておらず、ウェブサイトは、この値がユーザーの本当の希望を反映していると信じてはいけません。このヘッダーで言語検出を行うと、使い勝手を損なう可能性があるため、サイトのデザイナーは使用することを避けてください。 -

{{HTTPHeader("Accept-Language")}} ヘッダーは、ユーザーの言語設定を示すために使用します。これは、quality factor を伴う値のリストです (例: "de, en;q=0.7")。既定値はたいてい、ユーザーエージェントのグラフィカルインターフェイスの言語に従いますが、ほとんどのブラウザーでは異なる言語設定を適用できます。

+- サイトデザイナーは常に、サーバーが選択した言語を変える手段を、例えばサイト上に言語切り替えメニューを提供するなりして提供するべきです。多くのユーザーエージェントは `Accept-Language` ヘッダーに、ユーザーインターフェイス言語に合わせた既定値を提供します。エンドユーザーは大抵、この設定を変更しません。変更する方法を知らなかったり、コンピューティング環境の都合で変更できなかったりするからです。 +- サーバーが選択した言語をユーザーが変更したら、サイトは言語検出を使用せず、明示的に指定された言語に従うべきです。言い換えると、このヘッダーを使用して適切な言語を選択するのは、サイトの入り口のページだけとするべきです。 -

変更された値はユーザーのフィンガープリントとして使用できることから 設定に基づくエントロピー が高まるため、値を変更することは推奨されていません。またウェブサイトは、この値がユーザーの本当の希望を反映していると信じてはいけません。ユーザー体験を低下させる可能性があるため、サイトデザイナーはこのヘッダーで言語を検出することに熱心になってはいけません:

+### `User-Agent` ヘッダー - +> **Note:** コンテンツの選択にこのヘッダーを使用することは、正当な使用方法ですが、ユーザーエージェントがどの機能に対応しているかを判断するためにこのヘッダーを頼ることは[悪い習慣であると考えられています](/ja/docs/Web/HTTP/Browser_detection_using_the_user_agent)。 -

User-Agent ヘッダー

+{{HTTPHeader("User-Agent")}} ヘッダーは、リクエストを送信するブラウザーを識別します。この文字列には、空白区切りで**製品トークン**や**コメント**のリストが含まれることがあります。 -
-

このヘッダーをコンテンツの選択に使用することは理にかなっていますが、ユーザーエージェントがどの機能をサポートしているかを判断するためにこのヘッダーを頼ることは 悪い習慣であると考えられています。

-
+**製品トークン**は `Firefox/4.0.1` のように、名称、スラッシュ '`/`'、バージョン番号で構成されます。ユーザーエージェントは好きなだけこれを入れることができます。**コメント**は、括弧で囲まれた任意の文字列です。当然ながら、その文字列内で括弧を使用することはできません。コメントの内部形式は標準化されておらず、従って各ブラウザーがさまざまなトークンをセミコロン '`;`' 区切りで入れています。 -

{{HTTPHeader("User-Agent")}} ヘッダーは、リクエストを送信するブラウザーを明らかにします。この文字列には、空白区切りでプロダクトトークンやコメントのリストが含まれるでしょう。

+### `Vary` レスポンスヘッダー -

プロダクトトークンは Firefox/4.0.1 のように、名称、スラッシュ '/'、バージョン番号で構成されます。これはユーザーエージェントの必要性に応じて、複数存在することがあります。コメント は、括弧で囲まれた自由な文字列です。当然ながら、その文字列内で括弧を使用することはできません。コメントの内部形式は標準化されておらず、従って各ブラウザがさまざまなトークンをセミコロン ';' 区切りで入れています。

+クライアントが送信する前出の `Accept-*` ヘッダーとは対照的に、 {{HTTPHeader("Vary")}} HTTP ヘッダーはウェブサーバーがレスポンスで送信します。これは、サーバーがサーバー駆動型コンテンツ交渉で使用したヘッダーのリストを示します。このヘッダーは交渉を再現できるように、判断基準のキャッシュを知らせるために必要であり、キャッシュが機能を果たすようにするとともに、ユーザーに誤ったコンテンツを提供することを防ぎます。 -

Vary レスポンスヘッダー

+特別な値 '`*`' は、サーバー駆動型コンテンツ交渉で適切なコンテンツを選ぶために、ヘッダーで与えられていない情報も使用することを表します。 -

クライアントが送信する前出の Accept-* ヘッダーとは対照的に、 {{HTTPHeader("Vary")}} HTTP ヘッダーはウェブサーバーがレスポンスで送信します。これは、サーバーがサーバー駆動型コンテントネゴシエーションで使用したヘッダーのリストを示します。このヘッダーはネゴシエーションを再現できるように、判断基準のキャッシュを知らせるために必要であり、キャッシュが機能を果たすようにするとともに、ユーザーに誤ったコンテンツを提供することを防ぎます。

+`Vary` ヘッダーは HTTP バージョン 1.1 で追加され、キャッシュが適切に働くようにするためのものです。サーバー駆動型コンテンツ交渉で動作させるためには、転送されたコンテンツを選択するためにサーバーが使用した基準をキャッシュが知らなければなりません。この方法で、キャッシュはコンテンツ選択のアルゴリズムを再生することを可能にして、サーバーへさらにリクエストを行うことなく適切なコンテンツを直接提供できるでしょう。当然ながらワイルドカード '`*`' は、背後にある要素をキャッシュで知ることができないため、キャッシュの生成を妨げます。詳しくは、 [HTTP キャッシュ > 変化するレスポンス](/ja/docs/Web/HTTP/Caching#varying_responses)を参照してください。 -

特別な値 '*' は、サーバー駆動型コンテントネゴシエーションで適切なコンテンツを選ぶために、ヘッダーで与えられていない情報も使用することを表します。

+## エージェント駆動型交渉 -

Vary ヘッダーは HTTP バージョン 1.1 で追加され、キャッシュが適切に働くようにするために必要です。サーバー駆動型コンテントネゴシエーションが機能するには、転送されたコンテンツを選択するためにサーバーが使用した基準を知るためのキャッシュが必要です。この方法で、キャッシュはコンテンツ選択のアルゴリズムを再生することを可能にして、サーバーへさらにリクエストを行うことなく適切なコンテンツを直接提供できるでしょう。当然ながらワイルドカード '*' は、背後にある要素をキャッシュで知ることができないため、キャッシュの生成を妨げます。

+サーバー駆動型交渉には、うまくスケーリングできないという欠点があります。交渉では、ひとつの機能に対してひとつのヘッダーを使用します。画面サイズ、解像度、または他の軸を使用したい場合は、新たな HTTP ヘッダーを作成する必要があります。このヘッダーを、すべてのリクエストで送信しなければなりません。ヘッダーが少ない場合は問題にはなりませんが、ヘッダーの数が増えると、最終的にはメッセージの大きさがパフォーマンスに影響を与える可能性があります。多くの詳細なヘッダーを送信するとエントロピーも多く送信されますので、 HTTP フィンガープリンティングの可能性やそれに伴うプライバシーの懸念が増大します。 -

エージェント駆動型ネゴシエーション

+HTTP では、もうひとつの交渉方法である**エージェント駆動型交渉**または**リアクティブ交渉**が利用できます。この場合、サーバーはあいまいなリクエストに直面したときに、利用可能な代替リソースへのリンクを含むページを送り返します。ユーザーはそのリソースを提示され、使用するリソースを選択します。 -

サーバー駆動型ネゴシエーションには少々弱点があり、うまくスケーリングできません。ネゴシエーションでは、ひとつの機能に対してひとつのヘッダーを使用します。例えばスクリーンサイズ、解像度、または他の寸法を使用したい場合は、新たな HTTP ヘッダーを作成しなければなりません。またヘッダーは、すべてのリクエストで送信しなければなりません。ヘッダーが少ない場合は問題になりにくいのですが、それらを掛け合わせた結果メッセージサイズがパフォーマンス低下の原因になるかもしれません。多くの詳細なヘッダーを送信するとエントロピーも多く送信されますので、HTTP フィンガープリンティングの可能性やそれに伴うプライバシーの懸念が増大します。

+![](httpnego3.png) -

HTTP は初期のうちから、もうひとつのネゴシエーション方法であるエージェント駆動型ネゴシエーションまたはリアクティブネゴシエーションを使用できます。このネゴシエーションではあいまいなリクエストが発生したときに、サーバーは使用可能なリソースへのリンクを含むページを返します。ユーザーにはそれらのリソースが差し出されて、そこから使用するものを選択します。

- -

- -

残念ながら HTTP 標準では使用可能なリソースを選択できるページの様式を定めておらず、このプロセスを容易に自動化できない状況です。サーバー駆動型ネゴシエーションのフォールバックのほかにも、この方法はほとんどの場合スクリプト、特に JavaScript のリダイレクトともに使用します。ネゴシエーション基準を確認した後、スクリプトがリダイレクトを実行します。第二の問題点は、実際のリソースを取り出すために複数のリクエストが必要であるため、ユーザーがリソースを利用可能になるのが遅れることです。

+残念ながら HTTP 標準では、使用可能なリソースを選択するためのページの様式を定めていないため、このプロセスを自動化することができません。この方法は、**サーバー駆動型交渉**のフォールバックのほかにも、スクリプト、特に JavaScript のリダイレクトで常に使われています。交渉基準を確認した後、スクリプトがリダイレクトを実行します。第二の問題点は、実際のリソースを取り出すために複数のリクエストが必要であるため、ユーザーがリソースを利用可能になるのが遅くなることです。 -- cgit v1.2.3-54-g00ecf