choice response

A choice response returns a representation of the best variant for the request, and may also return the variant list of the negotiable resource. It can be generated when the server has sufficient information to be able to choose the best variant on behalf the user agent, but may only be generated if this best variant is a neighboring variant. Choice responses are defined in section 10.2.

選択応答は、要求に対する最善の変種の表現を返しまして、 その折衝可能資源の変種目録をも返しても構いません。 一般にサーバーが利用者エージェントの代わりに最善の変種を選ぶことができる十分な情報を持っているときには選択応答を返すことができますが、 この最善の変種が隣接変種であるときには選択応答を生成することだけが許されます。 選択応答は10.2節で定義します。

A choice response returns a representation of the best variant for the request, and may also return the variant list of the negotiable resource. It can be generated when the server has sufficient information to be able to choose the best variant on behalf the user agent, but may only be generated if this best variant is a neighboring variant. For request from user agents which do not support transparent content negotiation, a server may always generate a choice response, provided that the variant returned is a neighboring variant. The variant returned in a choice response need not necessarily be listed in the variant list bound to the negotiable resource.

   A choice response merges a normal HTTP response from the chosen
   variant, a TCN header which specifies the "choice" response-type, and
   a Content-Location header giving the location of the variant.
   Depending on the status code, a choice response is cacheable unless
   indicated otherwise.

   Origin servers and proxy caches MUST construct choice responses with
   the following algorithm (or any other algorithm which gives equal end
   results for the client).

   In this algorithm, `the current Alternates header' refers to the
   Alternates header containing the variant list which was used to
   choose the best variant, and `the current variant list validator'
   refers to the validator of this list.  Section 10.4 specifies how
   these two items can be obtained by a proxy cache.

   The algorithm consists of four steps.

1. Construct a HTTP request message on the best variant resource by rewriting the request-URI and Host header (if appropriate) of the received request message on the negotiable resource.

折衝可能資源について受取った要求メッセージの Request-URI と (適当であれば) Host 頭を書き換えて最善の変種資源についての HTTP 要求メッセージを構築します。

2. Generate a valid HTTP response message, but not one with the 304 (Not Modified) code, for the request message constructed in step 1.

手順1で構築した要求メッセージに対する、 304 (未修正) 符号ではない妥当な HTTP メッセージを生成します。

In a proxy cache, the response can be obtained from cache memory, or by passing the constructed HTTP request towards the origin server. If the request is passed on, the proxy MAY add, modify, or delete If-None-Match and If-Range headers to optimize the transaction with the upstream server.

串キャッシュでは、応答はキャッシュ記憶から得たものであっても、 構築した HTTP 要求を起源サーバーに渡して得たものであっても構いません。 要求が渡される時には、串は上流サーバーとの転送の最適化のために If-None-Match 頭と If-Range 頭を追加したり修正したり削除したりしても構いません。

Note: the proxy should be careful not to add entity tags of non-neighboring variants to If-* (conditional) headers of the request, as there are no global uniqueness requirements for these tags.

注意 : 串は、要求の If-* (条件) 頭に非隣接変種の実体札を加えてしまわないように注意するべきです。 そのような実体札には大域固有性の要件はないからです。

3. Only in origin servers: check for an origin server configuration error. If the HTTP response message generated in step 2 contains a TCN header, then the best variant resource is not a proper end point in the transparent negotiation process, and a 506 (Variant Also Negotiates) error response message SHOULD be generated instead of going to step 4.

起源サーバーのみ : 起源サーバー設定誤りを検査します。手順2で生成された HTTP 応答メッセージが TCN 頭を含んでいる場合、 最善の変種資源は透過折衝過程の適当な終点ではありませんので、 手順4へ進む代わりに 506 (変種もまた折衝) 誤り応答メッセージを生成するべきです。

4. Add a number of headers to the HTTP response message generated in step 2.

a. Add a TCN header which specifies the "choice" response-type.

choice response-type を指定した TCN 頭を加えます。

b. Add a Content-Location header giving the location of the chosen variant. Delete any Content-Location header which was already present.

選択された変種の位置を与える Content-Location 頭を加えます。既存のすべての Content-Location 頭は削除します。

Note: According to the HTTP/1.1 specification [1], if the Content-Location header contains a relative URI, this URI is relative to the URI in the Content-Base header, if present, and relative to the request-URI if no Content-Base header is present.

注意 : HTTP/1.1 仕様書によれば、 Content-Location 頭が相対URI を含んでいる時は、この URI は Content-Base 頭があればその URI に、 Content-Base 頭がなければ Request-URI に相対とします。

c. If any Vary headers are present in the response message from step 2, add, for every Vary header, a Variant-Vary header with a copy of the contents of this Vary header.

手順2の応答メッセージに Vary 頭があれば、 各 Vary 頭について、この Vary 頭の内容の複製を持った Variant-Vary 頭を加えます。

d. Delete any Alternates headers which are present in in the response. Now, the current Alternates header MUST be added if this is required by the Negotiate request header, or if the server returns "re-choose" in the TCN response header. Otherwise, the current Alternates header MAY be added.

応答に Alternates 頭があればすべて削除します。 そして、 Negotiate 要求頭が要求しているか、 サーバーが TCN 応答頭で re-choose を返すのであれば、現在 Alternates 頭を加えなければなりません。 それ以外では、現在 Alternates 頭を加えても構いません。

Note: It is usually a good strategy to always add the current Alternates header, unless it is very large compared to the rest of the response.

注意 : 現在 Alternates 頭が応答の残りに比べて非常に大きいのでない限り、 これを常に加えるのは通常よい戦略です。

e. Add a Vary header to ensure correct handling by plain HTTP/1.1 caching proxies. This header can either be

• Vary: *

or a more elaborate header, see section 10.6.

f. To ensure compatibility with HTTP/1.0 caching proxies which do not recognize the Vary header, an Expires header with a date in the past MAY be added. See section 10.7 for more information.

g. If an ETag header is present in the response message from step 2, then extend the entity tag in that header with the current variant list validator, as specified in section 9.2.

Note: Step g. is required even if the variant list itself is not added in step d.

h. Only in proxy caches: set the Age header of the response to

•               max( variant_age , alternates_age )

where variant_age is the age of the variant response obtained in step 2, calculated according to the rules in the HTTP/1.1 specification [1], and alternates_age is the age of the Alternates header added in step d, calculated according to the rules in section 10.4.

Note that a server can shorten the response produced by the above algorithm to a 304 (Not Modified) response if an If-None-Match header in the original request allows it. If this is the case, an implementation of the above algorithm can avoid the unnecessary internal construction of full response message in step 2, it need only construct the parts which end up in the final 304 response. A proxy cache which implements this optimization can sometimes generate a legal 304 response even if it has not cached the variant data itself.

An example of a choice response is:

     HTTP/1.1 200 OK
     Date: Tue, 11 Jun 1996 20:05:31 GMT
     TCN: choice
     Content-Type: text/html
     Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT
     Content-Length: 5327
     Cache-control: max-age=604800
     Content-Location: paper.1
     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}}
     Etag: "gonkyyyy;1234"
     Vary: negotiate, accept, accept-language
     Expires: Thu, 01 Jan 1980 00:00:00 GMT

     <title>A paper about ....