リスト応答

リスト応答 (HTTP)

[17] リスト応答 (list response) は、異体リストを提供するための応答です。

仕様書

意味

[6] リスト応答は、折衝可能資源異体リストを返しますが、 異体データ自体は返しません >>5, >>3

構文

[12] リスト応答は任意の状態符号を使うことができますが、 300 が最適です >>5

[13] HTTP/1.0 クライアントの中には 300 応答を黙って無視するものがあることが知られており、かわりに 200 を使うこともできます >>5

[9] リスト応答TCN: list を含まなければなりません >>5, >>4

[10] リスト応答Alternates: ヘッダーVary: ヘッダーを含まなければなりません >>5

[14] Vary: は通常のキャッシュが正しく扱えるようにするべきですVary: * でも構いませんし、より詳細なものでも構いません。 >>5

[11] リスト応答は (HEAD 要求でなければ) 利用者が手動で最善の異体を選択できるような payload body を含まなければなりません >>5

文脈

[7] リスト応答は、要求に対する特定の最善の異体を返したくない、 あるいは返すことが認められていない時に生成できます >>5, >>3

[15] リスト応答を構築できるのは起源鯖のみです >>5

処理モデル

[8] 利用者エージェントは、透過内容折衝に対応していれば、 リスト応答を受信したら、自動的に最善の異体を選択し、 取得し、表示することができなければなりません >>5, >>18異体のいずれも受け入れられないなら、エラー表示できなければなりません >>18

[16] 状態符号などにもよりますが、基本的にリスト応答キャッシュ可能です >>5

[21] 透過内容折衝に対応するキャッシュは、Vary: ヘッダーで示された条件が一致しなかったとしても、キャッシュされた新鮮リスト応答を返すことができます >>20

歴史

[1] RFC 2295

list response
A list response returns the variant list of the negotiable resource, but no variant data. It can be generated when the server does not want to, or is not allowed to, return a particular best variant for the request. List responses are defined in section 10.1.

目録応答は、折衝可能資源変種目録を返し、 変種のデータは返しません。 サーバー要求についての特定の最善変種を返すことを望まないか、 又は返すことが許されていないときに、目録応答を生成することができます。 目録応答は10.1節で定義します。

[2] RFC 2295 (HTTP 透過内容折衝) 10.1 List response

A list response returns the variant list of the negotiable resource, but no variant data. It can be generated when the server does not want to, or is not allowed to, return a particular best variant for the request. If the user agent supports transparent content negotiation, the list response will cause it to select a best variant and retrieve it.

目録応答折衝可能資源変種目録を返しますが変種データは返しません。 目録応答はその要求に最善の特定の変種を返すことをサーバーが望まないか、 または認められていないときに生成できます。 利用者エージェント投下内容折衝に対応する場合は、 目録応答は最善の変種を選択させてそれを取り出させることになります。

A list response MUST contain (besides the normal headers required by HTTP) a TCN header which specifies the "list" response-type, the Alternates header bound to the negotiable resource, a Vary header and (unless it was a HEAD request) an entity body which allows the user to manually select the best variant.

目録応答は (HTTP で必要とされている通常の頭の他に) list response-type を指定した TCN 頭と折衝可能資源に束縛された Alternates 頭、 Vary 頭と利用者が手動で最善の変種を選択できる実体本体を含まなければなりません

An example of a list response is

     HTTP/1.1 300 Multiple Choices
     Date: Tue, 11 Jun 1996 20:02:21 GMT
     TCN: list
     Alternates: {"paper.1" 0.9 {type text/html} {language en}},
                 {"paper.2" 0.7 {type text/html} {language fr}},
                 {"paper.3" 1.0 {type application/postscript}
                     {language en}}
     Vary: negotiate, accept, accept-language
     ETag: "blah;1234"
     Cache-control: max-age=86400
     Content-Type: text/html
     Content-Length: 227
     <h2>Multiple Choices:</h2>
     <ul>
     <li><a href=paper.1>HTML, English version</a>
     <li><a href=paper.2>HTML, French version</a>
     <li><a href=paper.3>Postscript, English version</a>
     </ul>

Note: A list response can have any status code, but the 300 (Multiple Choices) code is the most appropriate one for HTTP/1.1 clients. Some existing versions of HTTP/1.0 clients are known to silently ignore 300 responses, instead of handling them according to the HTTP/1.0 specification [2]. Servers should therefore be careful in sending 300 responses to non-negotiating HTTP/1.0 user agents, and in making these responses cacheable. The 200 (OK) status code can be used instead.

注意 : 目録応答はどんな状態符号をも持ち得ますが、 300 (複数選択肢) 符号が HTTP/1.1 クライアントには最適です。 既存の版の HTTP/1.0 クライアントの中には 300 応答を HTTP/1.0 仕様書に従って処理せずに黙って無視するものがあることが知られています。 従ってサーバーは折衝を行わない HTTP/1.0 利用者エージェントへの応答に 300 応答を送ることとその応答をキャッシュ可能にすることに注意するべきです。 200 (OK) 状態符号を代わりに使うことが出来ます。

The Vary header in the response SHOULD ensure correct handling by plain HTTP/1.1 caching proxies. This header can either be

応答中の Vary 頭は普通の HTTP/1.1 のキャッシュするが正しく扱うようにするべきです。 この頭は

  • Vary: *

or a more elaborate header; see section 10.6.1.

とするか、またはより詳細な頭とすることができます。

Only the origin server may construct list responses. Depending on the status code, a list response is cacheable unless indicated otherwise.

According to the HTTP/1.1 specification [1], a user agent which does not support transparent content negotiation will, when receiving a list response with the 300 status code, display the entity body included in the response. If the response contains a Location header, however, the user agent MAY automatically redirect to this location.

The handling of list responses by clients supporting transparent content negotiation is described in sections 11.1 and 13.