[3] [DFN[[RUBYB[[[透過内容折衝]]]@en[transparent content negotiation]]]]は、 [[HTTP]] の[[内容折衝]]の手法の一つです。 [[Apache]] が実装していますが、 あまり利用されていません。 * 仕様書 [REFS[ - [5] [CITE@en[RFC 2295 - Transparent Content Negotiation in HTTP]] ([TIME[2014-08-31 19:36:42 +09:00]] 版) -- [14] [CITE@en[RFC 2295 - Transparent Content Negotiation in HTTP]] ([TIME[2014-08-31 19:36:42 +09:00]] 版) -- [2] [CITE@en[RFC 2295 - Transparent Content Negotiation in HTTP]] ([TIME[2014-08-31 19:36:42 +09:00]] 版) -- [17] [CITE@en[RFC 2295 - Transparent Content Negotiation in HTTP]] ([TIME[2014-08-31 19:36:42 +09:00]] 版) -- [10] [CITE@en[RFC 2295 - Transparent Content Negotiation in HTTP]] ([TIME[2014-08-31 19:36:42 +09:00]] 版) -- [12] [CITE@en[RFC 2295 - Transparent Content Negotiation in HTTP]] ([TIME[2014-08-31 19:36:42 +09:00]] 版) ]REFS] * 呼称 [28] [[透過内容折衝]]の他、[DFN[透過折衝]]など表記揺れと思われるものがあります。 ;; [29] 厳密であるべき技術仕様書がそんなんでいいのかと思いますが、 [[IETF]] ではよくあることです。 * プロトコル [6] 次の[[応答]]の種別があります。 [FIG(short list)[ - [[リスト応答]] - [[選択応答]] - [[暫定応答]] ]FIG] [7] 次の[[ヘッダー]]があります。 [FIG(short list)[ - [CODE(HTTP)@en[[[Accept-Features:]]]] - [CODE(HTTP)@en[[[Alternates:]]]] - [CODE(HTTP)@en[[[Negotiate:]]]] - [CODE(HTTP)@en[[[TCN:]]]] - [CODE(HTTP)@en[[[Variant-Vary:]]]] ]FIG] [8] 次の[[状態符号]]があります。 [FIG(short list)[ - [CODE(HTTP)@en[[[300]]]] ]FIG] [9] その他次の概念があります。 [FIG(short list)[ - [[特徴タグ]] - [[特徴集合]] - [[特徴述語]] - [[異体リスト]] - [[遠隔変種選択アルゴリズム]] - [[透過的折衝可能資源]] - [[変種資源]] - [[隣接異体資源]] - [[構造化実体タグ]] ]FIG] [13] [[透過内容折衝]]は、 [CODE(HTTP)@en[[[GET]]]] と [CODE(HTTP)@en[[[HEAD]]]] にのみ適用されます [SRC[>>12]]。 [24] [[鯖]]は、 [[透過内容折衝資源]]への[[要求]]に対して、 [CODE[2xx]] または [CODE[3xx]] ([CODE[304]] を除く。) の[[応答]]を返す場合に、 [[目録応答]]、 [[選択応答]]、 [[臨時応答]]のいずれかとしなければ[MUST[なりません]]。 その種別は [CODE[TCN:]] [[ヘッダー]]で指定しなければ[MUST[なりません]]。 [SRC[>>22]] [25] [[鯖]]は、 [[透過内容折衝資源]]への[[要求]]に対して、 それ以外の[[状態符号]]の場合であっても、 [CODE[TCN:]] [[ヘッダー]]を含めることが[MAY[できます]]。 [SRC[>>22]] [26] [[鯖]]は、 [[目録応答]]、 [[選択応答]]、 [[臨時応答]]を構築した後に、 [[要求]]の [CODE[If-No-Match:]] [[ヘッダー]]や [CODE[If-Range:]] [[ヘッダー]]に応じて [CODE[304]] や [CODE[206]] の[[応答]]を返すことが[MAY[できます]]。 [[実体タグ]]は、 [[目録応答]]、 [[選択応答]]、 [[臨時応答]]を識別することになります。 [SRC[>>22]] [11] [[透過内容折衝]]の[[リスト応答]]、[[選択応答]]、[[暫定応答]]の決定は、 [[内容符号化]]、[[条件付き要求]]や[[範囲要求]]の処理よりも前に行います [SRC[>>10]]。 * 対応 [15] [[利用者エージェント]]が[[透過内容折衝]]に[DFN[[RUBYB[対応]@en[support]]]]するとは、 対応していることを示す [CODE(HTTP)@en[[[Negotiate:]]]] [[ヘッダー]]を送信することをいいます [SRC[>>14]]。 * [CODE(HTTP)@en[Negotiate: trans]] [18] [CODE(HTTP)@en[[[Negotiate:]]]] [[ヘッダー]]の[[指令]] [DFN[[CODE(HTTP)@en[[[trans]]]]]] は、[[利用者エージェント]]が現在の[[要求]]において[[透過内容折衝に対応]]していることを表します [SRC[>>17]]。 ;; [19] この値は [CODE(HTTP)@en[[[vlist]]]]、 [CODE(HTTP)@en[[[guess-small]]]]、 [[RVSA]] の版、 [CODE(HTTP)[[[*]]]] を指定することによっても暗示されます [SRC[>>17]]。 * 関連 [23] 他の手法については[[内容折衝]]参照。 * 歴史 [4] [[RFC 2295]] は従来の「[[HTTP/1.0]] [[内容折衝]]」に対するものとして[[透過内容折衝]]を説明しており、 既に用いられている実質的な標準である既存の[[内容折衝]]に対して [[IETF]] で標準化された [[HTTP/1.1]] 世代の新仕様として旧世代の手法を置き換えることを狙っていたことがうかがえます。 [FIG(quote)[ [FIGCAPTION[ [1] [CITE@en[RFC 2295 - Transparent Content Negotiation in HTTP]] ([TIME[2014-08-31 19:36:42 +09:00]] 版) ]FIGCAPTION] > :supports transparent content negotiation: From the viewpoint of an origin server or proxy, a user agent supports transparent content negotiation if and only if it sends a Negotiate header (section 8.4) which indicates such support. > :透過内容折衝に対応:[[起源サーバー]]又は[[串]]の視点から、 [[利用者エージェント]]が透過内容折衝に対応していることを示す [CODE(HTTP)[[[Negotiate]]]] 頭を送る場合、この場合に限って、 その利用者エージェントは透過内容折衝に[DFN[対応している]]といいます。 ]FIG] [16] [[RFC 2295]] は、従来の[[内容折衝]]は[[鯖]]に沢山の情報を送信しなければならず、 転送量が多いこと、[[プライバシー]]上の問題があることから、 すべての情報を送信せずとも[[クライアント]]側で[[最善の異体]]を選択できる[[透過内容折衝]]が有用であると主張しています。 ただし、[[異体リスト]]からいずれかの[[異体資源]]を選択して[[要求]]を送信させることにより、 [[プライバシー]]に関わる情報を収集することを完全には回避できないとも指摘しています。 ** 応答についての規定 [FIG(quote)[ [22] [[RFC 2295]] (HTTP 透過内容折衝) 10 Content negotiation responses > If a request on a transparently negotiated resource yields a response with a 2xx status code or any 3xx status code except 304, this response MUST always be either a list response, a choice response, or an adhoc response. These responses MUST always include a TCN header which specifies their type. Transparently negotiated responses with other status codes MAY also include a TCN header. [[透過内容折衝資源]]の要求が [CODE(HTTP)[[[2xx]]]] 状態符号又は [CODE(HTTP)[[[304]]]] を除く [CODE(HTTP)[[[3xx]]]] 状態符号の応答を得る場合、 この応答は常に[[目録応答]]か[[選択応答]]か[[臨時応答]]のいずれかでなければ'''なりません'''。 これらの応答は常にその型を指定した [CODE(HTTP)[[[TCN]]]] 頭を含まなければ'''なりません'''。 他の状態符号の透過折衝資源も [CODE(HTTP)[TCN]] 頭を含んでも'''構いません'''。 > The conditions under which the different content negotiation responses may be sent are defined in section 12.1 for origin servers and in section 13 for proxies. > After having constructed a list, choice, or adhoc response, a server MAY process any If-No-Match or If-Range headers in the request message and shorten the response to a 304 (Not Modified) or 206 (Partial Content) response, following the rules in the HTTP/1.1 specification [1]. In this case, the entity tag of the shortened response will identify it indirectly as a list, choice, or adhoc response. 目録応答, 選択応答または臨時応答を構築した後に、 サーバーは要求メッセージの [CODE(HTTP)[[[If-No-Match]]]] 頭又は [CODE(HTTP)[[[If-Range]]]] 頭を [[HTTP/1.1]] 仕様書に従って処理してこの応答を [CODE(HTTP)[[[304]]]] (未修正) 応答又は [CODE(HTTP)[[[306]]]] (部分内容) 応答に短しめても'''構いません'''。 この場合、短しめた応答の[[実体札]]は間接的に目録応答, 選択応答または臨時応答を識別することとなります。 *10.1 List response [CODE(WikiPage)[[[目録応答]>>2]]]を参照。 *10.2 Choice response [CODE(WikiPage)[[[選択応答]>>2]]]を参照。 *10.3 Adhoc response →[CODE(WikiPage)[[[臨時応答]>>3]]] *10.4 Reusing the Alternates header [CODE(WikiPage)[[[Alternates]>>6]]]を参照。 *10.5 Extracting a normal response from a choice response [CODE(WikiPage)[[[選択応答]]]]を参照。 *10.6 Elaborate Vary headers →[CODE(WikiPage)[[[Vary]>>32]]] を参照。 *10.7 Adding an Expires header for HTTP/1.0 compatibility →[CODE(WikiPage)[[[Expires]>>13]]] を参照。 *10.8 Negotiation on content encoding →[CODE(WikiPage)[[[内容符号化]>>1]]]を参照。 ]FIG] [FIG(quote)[ [27] [[RFC 2068]]・[[RFC 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. [DFN[透過折衝]]は、[[サーバー駆動折衝]]と[[エージェント駆動折衝]]の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. 透過折衝には、本来[[起源サーバー]]が必要であった折衝を分散させることができ、 キャッシュが正しい応答を正しく推測できるならエージェント折衝の二番目の[[要求]]の[RUBY[間] [ま]]をなくすこともできるという利点があります。 > 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 [DEL[and]] [INS[that could be]] used within HTTP/1.1. [DEL[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]] で使うことのできる拡張として開発することを妨げてもいません。 [DEL[透過折衝を行う HTTP/1.1 キャッシュは、応答がキャッシュ可能であるなら、全ての HTTP/1.1 [[クライアント]]に正しく解釈されるようにするため、その応答中に (変化の次元を定義する) [CODE(HTTP)[[[Vary]]]] 頭欄を含めなければ'''なりません'''。起源サーバーにより供給されるエージェント折衝情報は透過折衝した応答に含める'''べきです'''。]] ]FIG] ** [301] [CITE@en[Re: Status of RFC 2295: Transparent Content Negotiation in HTTP (Experimental)]] ( ([[Mark Nottingham]] 著, [TIME[2009-01-14 15:53:21 +09:00]] 版)) * メモ [20] [[透過内容折衝]]あるいは [[RFC 2295]] に対応している、対応する必要があるなどと述べている仕様書や文献も稀にありますが、そのほとんどは実態が伴っておらず、ただの [[HTTP]] 本体の[[内容折衝]]に過ぎなかったり、ただ言及しているに過ぎなかったりします。 [21] [[Apache]] が実装して[[鯖]]としては広く普及しているにも関わらず、 驚くほど使われておらず、存在すらあまり知られていない不思議な機能です。