Alternates:

Alternates: ヘッダー (HTTP)

[45] Alternates: ヘッダーは、 当該対象資源について利用できる異体の一覧を含めるものです。 HTTP 内容折衝の仕組みの一部として規定されていますが、 あまり使われていない内容折衝の中でも特にほとんど使われていません。

仕様書

意味

[28] Alternates: ヘッダーは、 折衝可能資源異体の一覧や内容折衝に関する指令を示すものです >>25

[64] Alternates: ヘッダーで伝達できる異体説明の一覧のことを異体リストといいます。

構文

[31] Alternates: ヘッダーの値は1つ以上変種説明 (またはフォールバック指定) や指令リスト (#) です >>25

  1. |
    1. 変種説明
    2. fallback-variant
    3. 指令
  2. *
    1. OWS
    2. ,
    3. OWS
    4. |
      1. 変種説明
      2. fallback-variant
      3. 指令

[39] フォールバックは複数指定できません >>25

[40] 必要があれば同じ変種を (違う説明で) 複数指定しても構いません >>25

[32] 引数 (指令) は名前のみ、または名前と = と値を指定するものです。 名前は字句、値は字句または引用文字列です。 >>25

  1. 字句
  2. ?
    1. =
    2. |
      1. 字句
      2. 引用文字列
[37] 名前の解釈は明記されていませんが、唯一の引数では構文より大文字・小文字不区別となっています。
[38] 同名の引数の可否や処理は明記されていません。

文脈

[52] リスト応答には Alternates: ヘッダーを含まなければなりません >>51

[54] 選択応答には Alternates: ヘッダーを含めるのが良いとされています >>53

[56] 臨時応答には Alternates: ヘッダーを含めることができます >>55

[61] 要求Negotiate: vlistNegotiate: guess-small が指定された場合には、 原則として応答Alternates: ヘッダーを含めなければなりません >>62

[29] 透過的折衝可能資源からの応答Alternates: ヘッダーを含める場合には、折衝可能資源に束縛された変種リストの完全なものを含めなければなりません >>25

[30] 透過内容折衝に対応しない資源からの応答にも Alternates: ヘッダーを含めることができます >>25

[46] TCN: re-choose を含めた応答には Alternates: も含めなければなりません >>8

[26] / への message/coffeepot 要求に対する応答Alternates: ヘッダーを含むべきです >>21

message/coffeepot も参照。

[27] / への message/teapot 要求に対する応答Alternates: ヘッダーを含まなければなりません >>21。 茶はまだ沸かしません。

[43] このヘッダーは複数指定できます。

基底 URL

[33] このヘッダー変種説明 (やフォールバック) の URL は、要求URLに対するものです >>25

指令

[41] 次の指令が規定されています。

[42] 理解できない指令は無視するべきです >>25

[44] IANA登録簿は用意されていないようです。

処理モデル

[34] 利用者エージェントはどの変種説明も受け入れられない時は、 フォールバックの指定があればそれを選択するべきです >>25

[35] 利用者エージェントは同位の変種が複数ある時は、 最初のものを選択するべきです >>25

[36] フォールバックが複数ある場合も最初のものを選択するのでしょうか。

[24] HTCPCP-TEA クライアントBREW 要求に対する応答Alternates: ヘッダーの内容を検査して、 適切な URL を選んで次の要求を送信しなければなりません >>21

[47] キャッシュは、複数の応答が同じ異体リスト検証子を持つなら、 両者の Alternates: ヘッダー等価として扱うことができます。 (ただし両者が同一である必要はありません。) >>48

[58] キャッシュは、折衝可能資源キャッシュ可能新鮮ETag:Alternates: を持っていれば、 Alternates:異体リスト検証子を取り出して、 利用者エージェントに代わって折衝したり、 選択応答を構築したりするために再利用して構いません。 >>57, >>63

[60] その場合 Vary: も再利用できます。 Vary: 参照。

[59] Alternates: ヘッダーは、 それが含まれていた応答です >>57

歴史

RFC 2068

[12] RFC 2068 (HTTP/1.1) 19.6.2.1 Alternates

The Alternates response-header field has been proposed as a means for the origin server to inform the client about other available representations of the requested resource, along with their distinguishing attributes, and thus providing a more reliable means for a user agent to perform subsequent selection of another representation which better fits the desires of its user (described as agent-driven negotiation in section 12).

Alternates 応答頭欄は、 要求された資源に他の利用可能な表現があることを、 その分別属性と共に起源サーバークライアントに知らせる手段として提案されています。 これによって、利用者エージェントが利用者の希望により合致する他の表現の選択を行うにあたってのより信頼できる手段を提供することとなります (12章でエージェント駆動折衝として説明されています)。

The Alternates header field is orthogonal to the Vary header field in that both may coexist in a message without affecting the interpretation of the response or the available representations. It is expected that Alternates will provide a significant improvement over the server-driven negotiation provided by the Vary field for those resources that vary over common dimensions like type and language.

Alternates 頭欄は Vary 頭欄と直交するので、 応答の解釈や利用可能な表現に影響なくメッセージに共存できます。 Alternates によって、型や言語のように共通な次元で変化する資源の Vary 欄によるサーバー駆動折衝が極めて向上することが期待されます。

The Alternates header field will be defined in a future specification.

Alternates 頭欄は将来の仕様書で定義されます。

[2] RFC 2068 よ、そこまで期待させておいて (ほんとはしてないけど☆) 最後にそういう落ちかよって突っ込みたくなるような(w

[3] Alternates 欄は今はなき URI: 欄の代替の一翼を担うと期待されていました。 (RFC 2068 19.6.2.5 参照。)

1998年

[66] >>65 では HTTP に加えて電子メールでも利用することが提案されていました。

RFC 2295

[13] RFC 2295 (HTTP 透過内容折衝) 8.3 Alternates

The Alternates response header is used to convey the list of variants bound to a negotiable resource. This list can also include directives for any content negotiation process. If a response from a transparently negotiable resource includes an Alternates header, this header MUST contain the complete variant list bound to the negotiable resource. Responses from resources which do not support transparent content negotiation MAY also use Alternates headers.

Alternates 応答頭は、折衝可能資源に束縛された変種の目録を伝達するのに使います。 この目録は任意の内容折衝手続きの指令を含めることもできます。 透過折衝可能資源からの応答が Alternates 頭を含んでいる場合は、 この頭は折衝可能資源に束縛された完全な変種目録を含まなければなりません。 透過内容折衝に対応していない資源からの応答も Alternates 頭を使って構いません

       Alternates = "Alternates" ":" variant-list

       variant-list = 1#( variant-description
                        | fallback-variant
                        | list-directive )

       fallback-variant = "{" <"> URI <"> "}"

       list-directive = ( "proxy-rvsa" "=" <"> 0#rvsa-version <"> )
                        | extension-list-directive

       extension-list-directive =
                        token [ "=" ( token | quoted-string ) ]

An example is

     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}},
                 proxy-rvsa="1.0, 2.5"

Any relative URI specified in a variant-description or fallback-variant field is relative to the request-URI. Only one fallback-variant field may be present. If the variant selection algorithm of the user agent finds that all described variants are unacceptable, then it SHOULD choose the fallback variant, if present, as the best variant. If the user agent computes the overall quality values of the described variants, and finds that several variants share the highest value, then the first variant with this value in the list SHOULD be chosen as the best variant.

variant-description 欄や fallback-variant 欄に指定されている相対URIRequest-URI について相対です。 fallback-variant 欄は1つだけ指定できます。利用者エージェント変種選択算法がすべての記述された変種が受け入れ不能であるとわかったときには、 fallback 変種があればこれを最善の変種として選ぶべきです。 利用者エージェントが記述された変種の全体品質値を計算し、 複数の変種が同位最高値を取るとわかったときには、 そのうちの目録中で最初の変種を最善の変種として選ぶべきです

The proxy-rvsa directive restricts the use of remote variant selection algorithms by proxies. If present, a proxy MUST ONLY use algorithms which have one of the version numbers listed, or have the same major version number and a higher minor version number as one of the versions listed. Any restrictions set by proxy-rvsa come on top of the restrictions set by the user agent in the Negotiate request header. The directive proxy-rvsa="" will disable variant selection by proxies entirely. Clients SHOULD ignore all extension-list-directives they do not understand.

proxy-rvsa 指令は、による遠隔変種選択算法の使用を制限します。 この指令があるときは、串は列挙された版番号か、大版番号が同じで小版番号が列挙されたものよりも大きい版の算法だけを使わなければなりませんproxy-avsa 指令によって設定された制限は、 Negotiate 要求頭で利用者エージェントによって設定された制限の上にきます。 指令 proxy-avsa="" は、串による変種選択を完全に無効化します。 クライアントは、その理解しないすべての extension-list-directive を無視するべきです

A variant list may contain multiple differing descriptions of the same variant. This can be convenient if the variant uses conditional rendering constructs, or if the variant resource returns multiple representations using a multipart media type.

変種目録は同じ変種についての複数の異なる記述を含んでいても構いません。 これはその変種が条件付レンダリング構造を使っているか、 その変種資源が複数部分媒体型を使って複数の表現を返す時に便利でしょう。

[14] RFC 2295 (HTTP 透過内容折衝) 10.4 Reusing the Alternates header

[6]

If a proxy cache has available a negotiated response which is cacheable, fresh, and has ETag and Alternates headers, then it MAY extract the Alternates header and associated variant list validator from the response, and reuse them (without unnecessary delay) to negotiate on behalf of the user agent (section 13) or to construct a choice response (section 10.2). The age of the extracted Alternates header is the age of the response from which it is extracted, calculated according to the rules in the HTTP/1.1 specification [1].

串キャッシュキャッシュ可能新鮮ETag 頭と Alternates 頭を持った折衝応答を利用可能なときは、 応答から Alternates 頭と関連付けられた変種目録検証子を取り出して (不要な遅延なく) 利用者エージェントの代わりに折衝したり選択応答を構築したりするのに再利用しても構いません。 取り出した Alternates 頭のは HTTP/1.1 仕様書の規則に従って算出した、それを取り出した応答の齢です。

RFC 2616

[4] RFC 2616 はあまり使われていない >>14 として削除しています。 RFC 2295 にはなぜか言及していません。

[17] RFC 2295廃止しようとするものでも無さそうです。

RFC 4429

[19] IANA登録簿へは RFC 4429RFC 2295 を出典として登録しています >>15, >>18

[20] 状態は「実験的」とされています >>15。ただし一覧表では空欄になっています >>18

RFC 723x

[10] RFC 2616 の改訂である RFC 7231 も、失敗した提案として Alternates: に言及しています (が RFC 2295 は今回も無視しています)。

[11] 代案として Link: ... rel=alternate に言及していますが、あまり本気でもなさそうです。

実装

[7] Virata-EmWeb というサーバーが送出するようです。

関連

[50] 構造化実体タグに含まれる異体リスト検証子は、 Alternates: ヘッダーについての検証子となります。

[22] HTCPCP-TEA 応答の例 >>21

Alternates: {"/darjeeling" {type message/teapot}},
            {"/earl-grey" {type message/teapot}},
            {"/peppermint" {type message/teapot}}

[23] HTCPCPHTCPCP-TEA 兼用のの例 >>21

Alternates: {"/" {type message/coffeepot}},
            {"/pot-0/darjeeling" {type message/teapot}},
            {"/pot-0/earl-grey" {type message/teapot}},
            {"/pot-1/peppermint" {type message/teapot}}

メモ

[5] この欄も、なんちゅーか、時代の流れに翻弄され続けたというか何と言うか、結局使われてない。。。