[17] リスト応答 (list response) は、異体リストを提供するための応答です。
[6] リスト応答は、折衝可能資源の異体リストを返しますが、 異体データ自体は返しません >>5, >>3。
[12] リスト応答は任意の状態符号を使うことができますが、 300 が最適です >>5。
300
200
[9] リスト応答は TCN: list を含まなければなりません >>5, >>4。
TCN: list
[10] リスト応答は Alternates: ヘッダーと Vary: ヘッダーを含まなければなりません >>5。
Alternates:
Vary:
Vary: *
[11] リスト応答は (HEAD 要求でなければ) 利用者が手動で最善の異体を選択できるような payload body を含まなければなりません >>5。
HEAD
[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 頭と利用者が手動で最善の変種を選択できる実体本体を含まなければなりません。
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>
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 のキャッシュする串が正しく扱うようにするべきです。 この頭は
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.
300
応答を黙って無視するものがあることが知られており、かわりに200
を使うこともできます >>5。