- [1] 【[[HTTP]] など】[[サーバー]]と[[クライアント]]の間で、クライアントが受け取る[[資源]]の形式 ([[媒体型]], [[言語]]など) を決定すべく交わされるやり取り, あるいはその概念の総称。 Content negotiation。 - [2] 略して [[conneg]] とも。 - [3] [[HTTP]] の内容折衝では、主として [CODE(HTTP)[[[Accept-*:]]]] 欄を使ってクライアントが受け付ける形式を主張する形で[[要求]]します。 - [4] [[電子メイル]]では、送られてきたメッセージに不満があればその旨を [[MDN]] で伝え、サーバーが送り直す形で実現しています。 [[RFC3297]] などで規定されています。 [5] [[HTTP]] ([[RFC2068]] 1.3, [[RFC2616]] 1.3) > :content negotiation:The mechanism for selecting the appropriate representation when servicing a request, as described in section 12. The representation of entities in any response can be negotiated (including error responses). :内容折衝:[[要求]]を service するときに適当な[[表現]]を選択する機構。 任意の応答中の[[実体]]の表現は折衝することができる ([[誤り応答]]を含む)。 * 仕様書から ** RFC 2068・2616 (HTTP/1.1) 12 Content Negotiation > Most HTTP responses include an entity which contains information for interpretation by a human user. Naturally, it is desirable to supply the user with the "best available" entity corresponding to the request. Unfortunately for servers and caches, not all users have the same preferences for what is "best," and not all user agents are equally capable of rendering all entity types. For that reason, HTTP has provisions for several mechanisms for "content negotiation" -- the process of selecting the best representation for a given response when there are multiple representations available. ほとんどの HTTP [[応答]]は、人間[[利用者]]が解釈する情報を含んだ[[実体]]を含んでいます。 当然、要求に対応する「利用可能な最善」の実体を利用者に供給するのが望ましいといえます。 [[サーバー]]や[[キャッシュ]]には嬉しくないことですが、 何が「最善」であるかに全ての利用者が同じものを好むわけではありませんし。 全ての[[利用者エージェント]]が全ての実体型を[[レンダリング]]する能力を等しく有しているわけでもありません。 こうした理由から、 HTTP は「内容折衝」という、 当該応答の複数の[[表現]]が利用可能なときに最善の表現を選択する処理のための機構を幾つか用意しています。 > Note: This is not called "format negotiation" because the alternate representations may be of the same media type, but use different capabilities of that type, be in different languages, etc. 注意 : 代替表現は同じ[[媒体型]]で、その型の異なる能力を使っていたり、 異なる言語で書かれていたりのような場合もあるので、「書式折衝」 とは呼びません。 > Any response containing an entity-body MAY be subject to negotiation, including error responses. There are two kinds of content negotiation which are possible in HTTP: server-driven and agent-driven negotiation. These two kinds of negotiation are orthogonal and thus may be used separately or in combination. One method of combination, referred to as transparent negotiation, occurs when a cache uses the agent-driven negotiation information provided by the origin server in order to provide server-driven negotiation for subsequent requests. [CODE(ABNF)[[[entity-body]]]] を含んだ任意の実体は、 [[誤り応答]]も含めて、折衝の対象にして'''構いません'''。 HTTP で可能な内容折衝には2種類あります。 この2種類の折衝は直行するものですから、 別々に使っても構いませんし、組合せても構いません。 組合せる方法の一つは、透過折衝と呼ばれるもので、 [[起源サーバー]]が以後の要求についての[[サーバー駆動折衝]]を提供するために提供した[[エージェント駆動折衝]]情報をキャッシュが使用するときに行われます。 *** 12.1 Server-driven Negotiation →[CODE(WikiPage)[[[サーバー駆動折衝]]]]参照。 *** 12.2 Agent-driven Negotiation →[CODE(WikiPage)[[[エージェント駆動折衝]]]]参照。 *** 12.3 Transparent Negotiation →[CODE(WikiPage)[[[透過折衝]]]]参照。 ** RFC の部分の License [[RFCのライセンス]] * メモ [6] アイデアのメモ。 ''問題'': [[日本語]]版と[[英語]]版がある [[Webサイト]]で、 [[リンク]]はすべて折衝が行われる [[URI]] を使って記述されている。 [CODE(HTTP)@en[[[Accept-Language]]]] で[[日本語]]を最優先にしていると、通常は[[日本語]]版が [[Webブラウザ]]に表示されるが、敢えて[[英語]]版が見たく、 [[Web頁]] [VAR@en[A.ja]] 内の[[リンク]]を使って [VAR@en[A.en]] に移動する。ここで、更に [VAR@en[A.en]] 内の[[リンク]]から [VAR@en[B]] に移動すると、[[日本語]]版が表示されてしまうのだが、 [[英語]]版の方が自然ではないか。 (あくまで例であり、言語以外に[[媒体型]]その他でもいい。 [[日本語]]も[[英語]]も [CODE(HTTP)@en[[[Accept-Language]]]] に入っていない場合というシナリオも興味深い。) ''すぐ思いつく対策'': [VAR@en[A.en]] 内の[[リンク]]先 [[URI]] は [VAR@en[B]] ではなく [VAR@en[B.en]] にすればよい。 ''すぐ思いつく対策の問題'': - [VAR@en[A]] の編集時に [VAR@en[B]] の何語版が存在しているか知っていなければならない。 - [VAR@en[B]] の言語非依存代表 [[URI]] を使う機会がないのがおもしろくない。 ''解'': [[Webブラウザ]]を修正する。 [CODE(HTML)@en[[[rel]]=[[alternate]]]] その他代替版への移動であることが明確な方法で頁遷移が行われた後は、 その[[リンク]]の情報 (例: [CODE(HTMLa)@en[[[hreflang]]]]) や[[リンク]]先の[[実体]]に付された情報 (例: [CODE(HTTP)@en[[[Content-Language]]]]) を[[内容折衝]]で優先的に使う ([CODE(HTTP)@en[[[Accept-Language]]]] で最優先にする)。 最優先にする対象範囲は、[[鯖]]全体か、 [[URI]] [CODE(ABNF)@en[[[path]]]] の階層によって決定する。 ''解の既知の問題'': - 一時的な代替版の選択。例えば印刷版や [[RSS]] 版を選択したとしても、それ以降ずっとその種類の版を選び続けたいとは限らない。 ''解の REST consideration'': [[認証]]と同じように、[[利用者]]には[[セッション]]に見えるかもしれないが実際には[[セッション]]ではない。 ''解の security consideration'': [[利用者]]の操作によって生成された[[内容折衝]]のための情報を[[鯖]]に送信することになるが、 privacy 上問題となるほど繊細なものではないと思われる。 ([[名無しさん]]) [7] [CITE[コンテントネゴシエーション - Apache HTTP サーバ]] ([[名無しさん]])