#?SuikaWiki/0.9 page-icon="HTTP"
* 仕様書から
** 定義
[1]
> [INS[[[RFC2295]] 2.2 抜粋]]
: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.
[DFN[目録応答]]は、[[折衝可能資源]]の[[変種目録]]を返し、
[[変種]]のデータは返しません。
[[サーバー]]が[[要求]]についての特定の最善変種を返すことを望まないか、
又は返すことが許されていないときに、目録応答を生成することができます。
目録応答は10.1節で定義します。
**RFC 2295 (HTTP 透過内容折衝) 10.1 List response
[2]
> 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]] で必要とされている通常の頭の他に)
[CODE(HTTP)[[[list]]]] [CODE(ABNF)[response-type]] を指定した
[CODE(HTTP)[[[TCN]]]] 頭と[[折衝可能資源]]に束縛された
[CODE(HTTP)[[[Alternates]]]] 頭、
[CODE(HTTP)[[[Vary]]]] 頭と利用者が手動で最善の変種を選択できる[[実体本体]]を含まなければ'''なりません'''。
> An example of a list response is
[PRE[
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
Multiple Choices:
]PRE]
> 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.
注意 : 目録応答はどんな[[状態符号]]をも持ち得ますが、
[CODE(HTTP)[[[300]]]] (複数選択肢) 符号が [[HTTP/1.1]] [[クライアント]]には最適です。
既存の版の [[HTTP/1.0]] クライアントの中には [CODE(HTTP)[300]]
応答を HTTP/1.0 仕様書に従って処理せずに黙って無視するものがあることが知られています。
従ってサーバーは折衝を行わない HTTP/1.0 利用者エージェントへの応答に
[CODE(HTTP)[300]] 応答を送ることとその応答を[[キャッシュ可能]]にすることに注意するべきです。
[CODE(HTTP)[[[200]]]] (OK) 状態符号を代わりに使うことが出来ます。
> The Vary header in the response SHOULD ensure correct handling by
plain HTTP/1.1 caching proxies. This header can either be
応答中の [CODE(HTTP)[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.
** RFC の部分の License
[[RFCのライセンス]]
* メモ