透過内容折衝に対応

透過内容折衝 (HTTP)

[3] 透過内容折衝 (transparent content negotiation) は、 HTTP内容折衝の手法の一つです。 Apache が実装していますが、 あまり利用されていません。

本項は歴史的事項を説明しています。本項の内容の一部または全部は、現在の状況とは異なるかもしれません。

(なお本項の内容の一部または全部は、互換性または歴史的連続性のために現在も有効な場合もあります。しかし新たに利用することは避けるべきです。)

目次

  1. 仕様書
  2. 呼称
  3. プロトコル
  4. 対応
  5. Negotiate: trans
  6. 関連
  7. 歴史
    1. 応答についての規定
    2. §
  8. メモ

仕様書#

呼称#

[28] 透過内容折衝の他、透過折衝など表記揺れと思われるものがあります。

[29] 厳密であるべき技術仕様書がそんなんでいいのかと思いますが、 IETF ではよくあることです。

プロトコル#

[6] 次の応答の種別があります。

[7] 次のヘッダーがあります。

[8] 次の状態符号があります。

[9] その他次の概念があります。

[13] 透過内容折衝は、 GETHEAD にのみ適用されます >>12

[24] は、 透過内容折衝資源への要求に対して、 2xx または 3xx (304 を除く。) の応答を返す場合に、 目録応答選択応答臨時応答のいずれかとしなければなりません。 その種別は TCN: ヘッダーで指定しなければなりません>>22

[25] は、 透過内容折衝資源への要求に対して、 それ以外の状態符号の場合であっても、 TCN: ヘッダーを含めることができます>>22

[26] は、 目録応答選択応答臨時応答を構築した後に、 要求If-No-Match: ヘッダーIf-Range: ヘッダーに応じて 304206応答を返すことができます実体タグは、 目録応答選択応答臨時応答を識別することになります。 >>22

[11] 透過内容折衝リスト応答選択応答暫定応答の決定は、 内容符号化条件付き要求範囲要求の処理よりも前に行います >>10

対応#

[15] 利用者エージェント透過内容折衝対応 (support) するとは、 対応していることを示す Negotiate: ヘッダーを送信することをいいます >>14

Negotiate: trans#

[18] Negotiate: ヘッダー指令 trans は、利用者エージェントが現在の要求において透過内容折衝に対応していることを表します >>17

[19] この値は vlistguess-smallRVSA の版、 * を指定することによっても暗示されます >>17

関連#

[23] 他の手法については内容折衝参照。

歴史#

[4] RFC 2295 は従来の「HTTP/1.0 内容折衝」に対するものとして透過内容折衝を説明しており、 既に用いられている実質的な標準である既存の内容折衝に対して IETF で標準化された HTTP/1.1 世代の新仕様として旧世代の手法を置き換えることを狙っていたことがうかがえます。

[1] RFC 2295 - Transparent Content Negotiation in HTTP ( 版) http://tools.ietf.org/html/rfc2295#page-8
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.
透過内容折衝に対応
起源サーバー又はの視点から、 利用者エージェントが透過内容折衝に対応していることを示す Negotiate 頭を送る場合、この場合に限って、 その利用者エージェントは透過内容折衝に対応しているといいます。

[16] RFC 2295 は、従来の内容折衝に沢山の情報を送信しなければならず、 転送量が多いこと、プライバシー上の問題があることから、 すべての情報を送信せずともクライアント側で最善の異体を選択できる透過内容折衝が有用であると主張しています。 ただし、異体リストからいずれかの異体資源を選択して要求を送信させることにより、 プライバシーに関わる情報を収集することを完全には回避できないとも指摘しています。

応答についての規定#

[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.

透過内容折衝資源の要求が 2xx 状態符号又は 304 を除く 3xx 状態符号の応答を得る場合、 この応答は常に目録応答選択応答臨時応答のいずれかでなければなりません。 これらの応答は常にその型を指定した TCN 頭を含まなければなりません。 他の状態符号の透過折衝資源も 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.

目録応答, 選択応答または臨時応答を構築した後に、 サーバーは要求メッセージの If-No-Match 頭又は If-Range 頭を HTTP/1.1 仕様書に従って処理してこの応答を 304 (未修正) 応答又は 306 (部分内容) 応答に短しめても構いません。 この場合、短しめた応答の実体札は間接的に目録応答, 選択応答または臨時応答を識別することとなります。

10.1 List response#

目録応答 (>>2)を参照。

10.2 Choice response#

選択応答 (>>2)を参照。

10.3 Adhoc response#

臨時応答 (>>3)

10.4 Reusing the Alternates header#

Alternates (>>6)を参照。

10.5 Extracting a normal response from a choice response#

選択応答を参照。

10.6 Elaborate Vary headers#

Vary (>>32) を参照。

10.7 Adding an Expires header for HTTP/1.0 compatibility#

Expires (>>13) を参照。

10.8 Negotiation on content encoding#

内容符号化 (>>1)を参照。

[27] RFC 2068RFC 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 頭欄を含めなければなりません。起源サーバーにより供給されるエージェント折衝情報は透過折衝した応答に含めるべきです

#

[301] Re: Status of RFC 2295: Transparent Content Negotiation in HTTP (Experimental) ( (Mark Nottingham 著, 版)) http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0016.html

メモ#

[20] 透過内容折衝あるいは RFC 2295 に対応している、対応する必要があるなどと述べている仕様書や文献も稀にありますが、そのほとんどは実態が伴っておらず、ただの HTTP 本体の内容折衝に過ぎなかったり、ただ言及しているに過ぎなかったりします。

[21] Apache が実装してとしては広く普及しているにも関わらず、 驚くほど使われておらず、存在すらあまり知られていない不思議な機能です。