[409] reactive negotiation (エージェント駆動折衝 (agent-driven negotiation) ) は、鯖が提供したリストに基づき利用者エージェントが表現を選択する内容折衝です。
[410] reactive negotiation では、 起源鯖が最初の応答に代替表現の資源のリストを含めます。 利用者エージェントはその応答に含まれる表現を用いても構いませんが、 それが最適だと考えない場合は、リストに示されたメタデータによりいずれか1つ以上の代替資源を選び、 GET 要求を発行します。 >>407
GET
300
[411] この代替資源の選択は、利用者エージェントによって自動的に行っても構いませんし、 メニューを生成して利用者に選ばせても構いません。 >>407
[412] 鯖は、代替資源のリストのみを送り、最初の表現を送らないことにしても構いません >>407。
[413] reactive negotiation は、型や言語や符号化のような共通の次元で異なっている時や、 要求から利用者エージェントの能力を判断しかねる時には有用です。 >>2
[414] reactive negotiation は、公開キャッシュによって鯖の負荷やネットワークの利用を削減している時にも有用です >>2。
[415] reactive negotiation はリストを送信しないといけないため転送時間が増えることや、 別の表現を得るために別の要求を送らないといけないといった欠点があります。 >>2
[421] 選択後の資源の取得は新たな GET 要求として行われるため、 GET 以外には reactive negotiation は簡単には使えません。 他の要求メソッドでも reactive negotiation を提供したければ、 結果を鯖側で別の GET 可能な URL に保存するなど、 proactive negotiation よりも複雑な処理が必要になります。
[408] RFC 2068・2616 (HTTP/1.1) 12.2 Agent-driven Negotiation
With agent-driven negotiation, selection of the best representation for a response is performed by the user agent after receiving an initial response from the origin server. Selection is based on a list of the available representations of the response included within the header fields (this specification reserves the field-name Alternates, as described in appendix 19.6.2.1) or entity-body of the initial response, with each representation identified by its own URI. Selection from among the representations may be performed automatically (if the user agent is capable of doing so) or manually by the user selecting from a generated (possibly hypertext) menu.
エージェント駆動折衝では、利用者エージェントは起源サーバーから最初の応答を受信した後で最善の表現の選択を行います。 最初の応答の頭欄又は entity-body の中には、それ自身の URI で識別される利用可能な表現の一覧が含まれていて、 これに基づいて選択します。 (この仕様書は Alternate という欄名を予約しています。) 表現の選択は (利用者エージェントにそうする能力があれば) 自動的に行っても構いませんし、 (おそらくハイパーテキストで) 生成されたメニューから利用者が手動で選択しても構いません。
entity-body
Alternate
Agent-driven negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language, or encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally when public caches are used to distribute server load and reduce network usage.
エージェント駆動折衝は、応答が広く使われている次元 (型、言語、符号化など) によって変化する場合や、 起源サーバーが要求を検査しても利用者エージェントの能力を決定できない場合や、 サーバーの負荷を分散させたりネットワークの使用を削減するために公開キャッシュが使われている一般的な場合に有利です。
Agent-driven negotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation. This second request is only efficient when caching is used. In addition, this specification does not define any mechanism for supporting automatic selection, though it also does not prevent any such mechanism from being developed as an extension and used within HTTP/1.1.
エージェント駆動折衝は、最善の代替表現を得るために二番目の要求を必要であるという欠点があります。 この二番目の要求はキャッシュが使われているときだけ有効です。 加えて、この仕様書は自動的選択に対応する機構を定義していません。 但し、そのような機構を拡張として開発して HTTP/1.1 で使うことも妨げてはいません。
HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable) status codes for enabling agent-driven negotiation when the server is unwilling or unable to provide a varying response using server-driven negotiation.
HTTP/1.1 は、サーバー駆動折衝を使って変化させた応答を提供するつもりがないか、 それができないときにエージェント駆動折衝を有効化する、 300 (複数選択肢) と 406 (受け入れ不能) の2つの状態符号を定義しています。
406
[420] RFC 2068・2616 (HTTP/1.1) 12.3 Transparent Negotiation
Transparent negotiation is a combination of both server-driven and agent-driven negotiation. When a cache is supplied with a form of the list of available representations of the response (as in agent-driven negotiation) and the dimensions of variance are completely understood by the cache, then the cache becomes capable of performing server-driven negotiation on behalf of the origin server for subsequent requests on that resource.
透過折衝は、サーバー駆動折衝とエージェント駆動折衝の2つの組合せです。 キャッシュが (エージェント駆動折衝として) 応答の利用可能な表現の一覧の形で供給された時は、 キャッシュはその資源についてサーバー駆動折衝応答ができるようになります。
Transparent negotiation has the advantage of distributing the negotiation work that would otherwise be required of the origin server and also removing the second request delay of agent-driven negotiation when the cache is able to correctly guess the right response.
透過折衝には、本来起源サーバーが必要であった折衝を分散させることができ、 キャッシュが正しい応答を正しく推測できるならエージェント折衝の二番目の要求の間 (ま) をなくすこともできるという利点があります。
This specification does not define any mechanism for transparent negotiation, though it also does not prevent any such mechanism from being developed as an extension and that could be used within HTTP/1.1. An HTTP/1.1 cache performing transparent negotiation MUST include a Vary header field in the response (defining the dimensions of its variance) if it is cachable to ensure correct interoperation with all HTTP/1.1 clients. The agent-driven negotiation information supplied by the origin server SHOULD be included with the transparently negotiated response.
この仕様書は、透過折衝の機構を定義していません。 しかし、そのような機構を HTTP/1.1 で使うことのできる拡張として開発することを妨げてもいません。 透過折衝を行う HTTP/1.1 キャッシュは、応答がキャッシュ可能であるなら、全ての HTTP/1.1 クライアントに正しく解釈されるようにするため、その応答中に (変化の次元を定義する) Vary 頭欄を含めなければなりません。起源サーバーにより供給されるエージェント折衝情報は透過折衝した応答に含めるべきです。
Vary
[416] reactive negotiation は HTTP 仕様書上の概念としては定義されているものの、 実際には利用者エージェントが自動的に選択できるリストの仕組みが HTTP 本体仕様書で定義されていないこともあり、現実にはほとんど用いられていません。
[417] Alternates: ヘッダーのようにリストを記述する仕組みが提案されてはいますが、 広く普及するには至っていません。
Alternates:
[418] 300 や 406 の応答により、 あるいは場合によっては 200 応答により、 利用者が選択できるメニューを含む HTML文書などが提供されることは、 しばしばあります。これも仕様上の reactive negotiation と言えなくはありません。 (>>411 の通り、手動による選択は明示的に認められています。) しかし、それは Web 上にありふれたただのハイパーリンクと技術的に何ら変わりありませんから、 敢えて内容折衝という概念で説明する必要もないでしょう。
200
[422] HTTP の原理主義的な人々の間では内容折衝は人気の機能であり、 未だに HTTP の仕様書には記述が残っていますが、今後も reactive negotiation が普及しそうな気配はありません。そもそも reactive negotiation がなければ実現できないことが存在していないので、 実装しようとする動きも利用しようとする動きも出てこないのでしょう。
[423] 利用者エージェントが利用者エージェント側の機能や環境などの条件によって処理を分けるという点では、 Media Queries が似た技術とも言えます。 HTML や CSS などでは Media Queries を使って環境ごとに異なるレンダリングや異なるスクリプトの処理を実行できます。 reactive negotiation とは違って1回のアクセスに複数の要求と応答の往復が必要にはなりませんし、 窓の大きさの変更などの環境の動的な変化にも対応できます。
[1] UA駆動折衝と訳した方が良いのかも・・・とか思いつつ。
UA駆動折衝
300
状態符号が用意されています。 ただし300
以外を使っても構わないようです。