choice

選択応答 (HTTP)

[12] 選択応答 (choice response) は、 透過内容折衝によってが選んだ異体を返す応答です。

仕様書

意味

[7] 選択応答は、要求最善の異体表現を返すものです >>6, >>4

[11] なお、選択応答で返される異体は必ずしも折衝可能資源に束縛された異体リストに挙げられたものでなくても構いません >>6

構文

[14] 起源鯖串キャッシュは、選択応答を次のように構築しなければなりません。ただし、 現在の Alternates: ヘッダーとは最善の異体を選ぶために使った異体リストを含む Alternates: ヘッダーを、 現在の異体リスト検証子とはその異体リスト検証子を指します。 >>6

  1. [15] 折衝可能資源に対して受信した要求対象URLを書き換えて、 最善の異体資源に対する要求を構築します。
  2. [16] それに対する応答 (304 でないもの。) を生成します。
  3. [18] 起源鯖の場合、設定エラーを検査します。生成した応答TCN: ヘッダーが含まれていれば、 506 応答を返してここで終わるべきです
  4. [19] 応答TCN: choice を追加します。
  5. [20] 応答に既に Content-Location: ヘッダーがあれば削除し、 かわりに選んだ異体の位置を示した Content-Location: ヘッダーを追加します。
  6. [21] 応答に既に Vary: ヘッダーがあれば、 Variant-Vary: ヘッダーに内容を複製します。
  7. [22] 応答に既に Alternates: ヘッダーがあれば削除します。
  8. [23] 要求Negotiate: ヘッダーで求められていれば、 またはTCN: re-choose を返すのであれば、 またはが望むのであれば、 応答に現在の Alternates: ヘッダーを追加します。
    • [24] 常に追加するのが良い戦略 (good strategy) です。
  9. [25] 応答Vary: * (またはより詳細なもの) を追加します。
  10. [26] 応答Expires: ヘッダーを追加しても構いません。
  11. [27] 応答ETag: ヘッダーがあれば、 現在の異体リスト検証子を追加して構造化実体タグとします。
  12. [28] 串キャッシュなら、 Age: ヘッダーの値を通常の規則によると現在の Alternates: ヘッダーの大きな方に設定します。
  13. [29] この応答を返します。

[8] なお、要求If-None-Match: ヘッダー次第で 304 応答を返しても構いません。その場合 >>14 の手順は簡略化でき、串キャッシュは当該異体データキャッシュしていなかったとしても 304 を返せることがあります。 >>6

[30] >>25>>26 は、透過内容折衝に対応しないキャッシュが不適切にキャッシュしてしまわないよう適切な値を設定することとなっています。
[31] この手順では re-choose を指定するタイミングが無いのですが・・・。
[36] 既存の Vary: を削除する必要は無いようです。

文脈

[9] 選択応答は、利用者エージェントにかわって最善の異体を選択する十分な情報がある時、その最善の異体隣接異体である場合に限り、生成できます >>6, >>4

[10] 透過内容折衝に対応しない利用者エージェントからの要求に対しては、 隣接異体が返されるのであれば、いつでも選択応答生成できます >>6

処理モデル

[45] 利用者エージェント選択応答に含まれる異体資源折衝可能資源隣接異体資源かどうか検査し、そうでない場合には拒絶するべきです >>42, >>32。 その場合、例えば 502 応答とすることによりエラーを表示できます >>42

[43] 利用者エージェントは通常は選択応答を受信したら、含まれている payload body を自動的に表示します >>42

[44] しかし利用者エージェント遠隔異体選択アルゴリズム局所異体選択アルゴリズムが違う異体を選ぶであろう場合には、 応答に含まれる異体リスト局所異体選択アルゴリズムを適用し、 他の異体を自動的に取得し、表示しても構いません >>42

[13] 選択応答は、状態符号その他に依存してキャッシュ可能です >>6

[33] キャッシュは、選択応答から通常の HTTP 応答を取り出し、これをキャッシュして構いません >>32, >>46 。通常の HTTP 応答を取り出すには、次のようにします。 >>32

  1. [34] 選択応答を複製します。
  2. [35] Content-Location:Alternates:Vary: を削除します。
  3. [37] Variant-Vary: があれば Vary: に書き換えます。
  4. [38] ETag: があれば構造化実体タグを通常の実体タグに書き換えます。

[39] >>33 で得られた通常の応答は、異体への要求に対する応答としてキャッシュし、以後その異体への直接要求に対する応答として再利用して構いません >>32

[40] ただし隣接異体資源でない通常の応答キャッシュしてはなりません >>32

歴史

[1] RFC 2295 2.2 抜粋

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節で定義します。

[2] RFC 2295 (HTTP 透過内容折衝) 10.2 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. 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 ....

RFC 2295 (HTTP 透過内容折衝) 10.5 Extracting a normal response from a choice response

If a proxy receives a choice response, it MAY extract and cache the normal HTTP response contained therein. The normal response can be extracted by taking a copy of the choice response and then deleting any Content-Location, Alternates, and Vary headers, renaming any Variant-Vary headers to Vary headers, and shortening the structured entity tag in any ETag header to a normal entity tag.

串が選択応答を受取った時に、その中の通常の HTTP 応答を取り出してキャッシュしても構いません。 通常の応答は、選択応答の複製を作って Content-Location 頭、 Alternates 頭、 Vary 頭をすべて削除し、すべての Variant-Vary 頭を Vary 頭に名前変更し、すべての ETag 頭中の構造化実体札を通常の実体札に短しめることで取り出せます。

This normal response MAY be cached (as a HTTP response to the variant request as constructed in step 1. of section 10.2) and reused to answer future direct requests on the variant resource, according to the rules in the HTTP/1.1 specification [1].

通常の応答は (10.2節の手順1で構築した変種要求に対する応答として) キャッシュして、 HTTP/1.1 仕様書の規則に従って将来の変種資源への直接要求に回答するのに再利用しても構いません

Note: The caching of extracted responses can decrease the upstream bandwidth usage with up to a factor 2, because two independent HTTP/1.1 cache entries, one associated with the negotiable resource URI and one with the variant URI, are created in the same transaction. Without this optimization, both HTTP/1.1 cache entries can only be created by transmitting the variant data twice.

For security reasons (see section 14.2), an extracted normal response MUST NEVER be cached if belongs to a non-neighboring variant resource. If the choice response claims to contain data for a non-neighboring variant resource, the proxy SHOULD reject the choice response as a probable spoofing attempt.

RFC 2295 (HTTP 透過内容折衝) 22 Appendix: Example of choice response construction

[3]

The following is an example of the construction of a choice response by a proxy cache which supports HTTP/1.1 and transparent content negotiation. The use of the HTTP/1.1 conditional request mechanisms is also shown.

次に挙げるのは、 HTTP/1.1 と透過内容折衝に対応した串キャッシュ選択応答を構築する例です。 HTTP/1.1 条件付要求機構の使用も示します。

Assume that a user agent has cached a variant list with the validator "1234" for the negotiable resource http://x.org/paper. Also assume that it has cached responses from two neighboring variants, with the entity tags "gonkyyyy" and W/"a;b". Assume that all three user agent cache entries are stale: they would need to be revalidated before the user agent can use them. If http://x.org/paper accessed in this situation, the user agent could send the following request to its proxy cache:

利用者エージェントは折衝可能資源 http://x.org/paper検証子 "1234"変種目録をキャッシュしているとします。 また、実体札"gonkyyyy"W/"a;b" の2つの隣接変種もキャッシュしているとします。 3つのすべての利用者エージェントキャッシュ項目は腐っているとします。 よって、利用者エージェントはこれらを使う前に再検証する必要があります。 この状況で http://x.org/paper に接続するとすれば、 利用者エージェントは串キャッシュに次の要求を送ることが出来ます。

     GET /paper HTTP/1.1
     Host: x.org
     User-Agent: WuxtaWeb/2.4
     Negotiate: 1.0
     Accept: text/html, application/postscript;q=0.4, */*
     Accept-Language: en
     If-None-Match: "gonkyyyy;1234", W/"a;b;1234"

Assume that the proxy cache has cached the same three items as the user agent, but that it has revalidated the variant list 8000 seconds ago, so that the list is still fresh for the proxy. This means that the proxy can run a remote variant selection algorithm on the list and the incoming request.

串キャッシュが同じ3つの項目をキャッシュしていて、 8000秒前に変種目録を再検証していて、串にとっては目録はまだ新鮮であるとします。 このことは、串が目録とやってくる要求で遠隔変種選択算法を動かせることを意味します。

Assume that the remote algorithm is able to choose paper.html.en as the best variant. The proxy can now construct a choice response, using the algorithm in section 10.2. In steps 1 and 2 of the algorithm, the proxy can construct the following conditional request on the best variant, and send it to the origin server:

遠隔算法が paper.html.en を最善の変種として選ぶことが出来たとします。 串は10.2節の算法を使って選択応答を構築することが出来ます。 その算法の手順1と手順2で、串は最善の変種についての次の条件付要求を構築し、 起源サーバーに送ることが出来ます。

     GET /paper.html.en HTTP/1.1
     Host: x.org
     User-Agent: WuxtaWeb/2.4
     Negotiate: 1.0
     Accept: text/html, application/postscript;q=0.4, */*
     Accept-Language: en
     If-None-Match: "gonkyyyy", W/"a;b"
     Via: 1.1 fred

On receipt of the response

     HTTP/1.1 304 Not Modified
     Date: Tue, 11 Jun 1996 20:05:31 GMT
     Etag: "gonkyyyy"

from the origin server, the proxy can use its freshly revalidated paper.html.en cache entry to expand the response to a non-304 response:

という応答を起源サーバーから受信し、串はこの応答を新鮮なものとして再検証された paper.html.en キャッシュ項目を使って非 304 応答に展開できます。

     HTTP/1.1 200 OK
     Date: Tue, 11 Jun 1996 20:05:31 GMT
     Content-Type: text/html
     Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT
     Content-Length: 5327
     Cache-control: max-age=604800
     Etag: "gonkyyyy"
     Via: 1.1 fred
     Age: 0

     <title>A paper about ....

Using this 200 response, the proxy can construct a choice response in step 4 of the algorithm:

この 200 応答を使って、串は算法の手順4の選択応答を構築できます。

     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.html.en
     Alternates: {"paper.html.en" 0.9 {type text/html} {language en}},
                 {"paper.html.fr" 0.7 {type text/html} {language fr}},
                 {"paper.ps.en"   1.0 {type application/postscript}
                     {language en}}
(篇注 : 空行ママ。たぶん誤り)
     Etag: "gonkyyyy;1234"
     Vary: negotiate, accept, accept-language
     Expires: Thu, 01 Jan 1980 00:00:00 GMT
     Via: 1.1 fred
     Age: 8000

     <title>A paper about ....

The choice response can subsequently be shortened to a 304 response, because of the If-None-Match header in the original request from the user agent. Thus, the proxy can finally return

利用者エージェントからの元の要求に If-None-Match 頭があるので、この選択応答は続いて 304 応答に短しめることができます。よって、串は最終的に

     HTTP/1.1 304 Not Modified
     Date: Tue, 11 Jun 1996 20:05:31 GMT
     Etag: "gonkyyyy;1234"
     Content-Location: paper.html.en
     Vary: negotiate, accept, accept-language
     Expires: Thu, 01 Jan 1980 00:00:00 GMT
     Via: 1.1 fred
     Age: 8000

to the user agent.

を利用者エージェントに返すことが出来ます。