サーバー駆動折衝

proactive negotiation (HTTP)

[3] 利用者エージェント希望に基づき表現を選択する内容折衝を、 proactive negotiation >>2 (鯖駆動折衝 (server-driven negotiation) ) といいます。

仕様書

処理モデル

[4] proactive negotiation は、要求によって利用者エージェントが送信した希望と、 利用可能な表現に基づき、表現を選択して応答とするものです。 選択においては、言語内容符号化などの特徴を、 利用可能な表現のものと、要求に明示された条件や User-Agent: などから暗示された条件などと何らかの方法で比較します。 >>2

C
利用者エージェント
S
C -> S
要求
#S#
要求から表現を選択
S -> C
選択した表現を含む応答

特徴

[5] proactive negotiation は、利用可能な表現からの選択方法を記述して利用者エージェントに提示するのが難しい時や、 余分なやり取りなしに最初の応答で良さげな表現を送りたい時には有用です。 >>2

[6] しかしは必ずしも良さげな表現を推定できるとは限りません。 利用者エージェントは推測を助けるためのヘッダーを送ることもできます >>2 が、利用者画面に表示したいのか印刷したいのか、 といった意図まで完全にが把握できるわけではありません >>2

[7] また、複数の表現がある場合が少ないとすると常にヘッダーを送るのは非効率ですし、 プライバシー的なリスクもあります。 >>2

[8] 起源鯖表現を選択するアルゴリズムが複雑になるのも欠点です >>2

[9] また、共有キャッシュの利用率も下がります >>2

[10] 利用者エージェントヘッダーを送っても、それが尊重されるとは限りません。 当該資源proactive negotiation が実装されていないかもしれませんし、 406 応答を送るより利用者エージェントの希望を満たさない表現を送った方がましと起源鯖が判断するかもしれません。 >>2

ヘッダー

[407] Vary: ヘッダーは、 proactive negotiation に際して要求のどの情報を用いたか示すために使うことがあります >>2

[11] 次のヘッダー鯖駆動折衝に使われるものです。

[14] この他 User-Agent:クライアントIPアドレス (IP によって示されたもののほか、 X-Forwarded-For: などのヘッダーによるものも含みます。) が内容折衝に使われることもあります。

[12] また通常は内容折衝には含めませんが、 TE: も同様に機能します。

[13] Prefer:内容折衝のために使うべきではないとされていますが、 Prefer: safe のように事実上の内容折衝のために使われることもあります。

[15] 新たな内容折衝の試みとして、 Client Hints が一部で実装されています。

セキュリティー

[16] クライアント情報を送るということは、 fingerprinting vector を提示するものであり、 プライバシー保護の観点から問題があると考えられています。

歴史

[1] RFC 2068・2616 (HTTP/1.1) 12.1 Server-driven Negotiation

If the selection of the best representation for a response is made by an algorithm located at the server, it is called server-driven negotiation. Selection is based on the available representations of the response (the dimensions over which it can vary; e.g. language, content-coding, etc.) and the contents of particular header fields in the request message or on other information pertaining to the request (such as the network address of the client).

応答の最善の表現の選択がサーバーに位置付けられた算法によって行われる時、 これをサーバー駆動折衝と呼びます。選択は、 利用可能な応答の表現 (その変化し得る次元、例えば言語、 content-coding など) 要求メッセージ中の特定の頭欄の内容や要求に関係するその他の情報 (クライアントのネットワーク番地など) に基づきます。

Server-driven negotiation is advantageous when the algorithm for selecting from among the available representations is difficult to describe to the user agent, or when the server desires to send its "best guess" to the client along with the first response (hoping to avoid the round-trip delay of a subsequent request if the "best guess" is good enough for the user). In order to improve the server's guess, the user agent MAY include request header fields (Accept, Accept-Language, Accept-Encoding, etc.) which describe its preferences for such a response.

サーバー駆動折衝は、利用可能な表現から選択する算法を利用者エージェントに説明するのが難しい時や、 (「最善の推測」が利用者にとって十分であるときの後続の要求の往復の () を避けることを願って) 最初の応答で「最善の推測」によるものをクライアントに送ることをサーバーが望む時に有利です。 サーバーの推測を向上させるために、利用者エージェントは応答の選り好みを記述した要求頭欄 (Accept, Accept-Language, Accept-Encoding など) を含めて構いません

Server-driven negotiation has disadvantages:

サーバー駆動折衝には不利な点もあります。

  • 1. It is impossible for the server to accurately determine what might be "best" for any given user, since that would require complete knowledge of both the capabilities of the user agent and the intended use for the response (e.g., does the user want to view it on screen or print it on paper?).
  • 2. Having the user agent describe its capabilities in every request can be both very inefficient (given that only a small percentage of responses have multiple representations) and a potential violation of the user's privacy.
  • 3. It complicates the implementation of an origin server and the algorithms for generating responses to a request.
  • 4. It may limit a public cache's ability to use the same response for multiple user's requests.
  • サーバーがその利用者にとって何が「最善」なのかを正確に決定するのは不可能です。 正確に決定するためには利用者エージェントの能力と応答をどう使うつもりか (例えば利用者が画面で見ることを望んでいるのか、紙に印刷することを望んでいるのか) の両方についての完全な知識が必要になってしまいます。
  • 利用者エージェントが毎度の要求でその能力を記述するのは (複数の表現を持つ応答がほんのわずかの割合だとしたら) とても非効率ですし、 利用者の個人情報を漏らしてしまう虞もあります。
  • 起源サーバーの実装と要求に対する応答を生成する算法を複雑化させてしまいます。
  • 公開キャッシュが同じ応答を複数の利用者の要求に使える場面を限定してしまうかもしれません。

HTTP/1.1 includes the following request-header fields for enabling server-driven negotiation through description of user agent capabilities and user preferences: Accept (section 14.1), Accept-Charset (section 14.2), Accept-Encoding (section 14.3), Accept-Language (section 14.4), and User-Agent (section 14.42 14.43). However, an origin server is not limited to these dimensions and MAY vary the response based on any aspect of the request, including information outside the request-header fields or within extension header fields not defined by this specification.

HTTP/1.1 は、利用者エージェント能力及び利用者の好みの記述によってサーバー駆動折衝を可能とするための要求頭欄として Accept, Accept-Charset, Accept-Encoding, Accept-Language, User-Agent を含んでいます。 しかし、起源サーバーはこれらの次元に限定されず、 要求頭欄外の情報やこの仕様書で定義していない拡張頭欄中の情報も含めて、 要求の任意の側面に基づいて応答を変化させて構いません

HTTP/1.1 origin servers MUST include an appropriate Vary header field (section 14.43) in any cachable response based on server-driven negotiation. The Vary header field describes the dimensions over which the response might vary (i.e. the dimensions over which the origin server picks its "best guess" response from multiple representations).

HTTP/1.1 起源サーバーは、サーバー駆動折衝に基づくキャッシュ可能な応答に適切な Vary 頭欄を含めなければなりませんVary 頭欄は、その応答が変化し得る次元 (すなわち、起源サーバーが複数の表現から「最善の推測」応答を選んだ次元) を記述します。

HTTP/1.1 public caches MUST recognize the Vary header field when it is included in a response and obey the requirements described in section 13.6 that describes the interactions between caching and content negotiation.

HTTP/1.1 公開キャッシュは、 Vary 頭欄が応答中に含まれているときは、 これを認識し、キャッシュと内容折衝の相互作用について説明した13.6節に記述されている要件に従わなければなりません

The Vary header field can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation. See section 13.6 for use of the Vary header field by caches and section 14.44 for use of the Vary header field by servers.

サーバーが内容折衝の対象である表現を選択するのに使った引数を表現するのに Vary 頭欄を使うことができます。 キャッシュの Vary 頭欄の利用については13.6節を、 サーバーの Vary 頭欄の使用については 14.44 節をご覧下さい。