[3] Accept-Features:
ヘッダーは、
対応している、あるいはしていない特徴を示すものです。
[11] Accept-Features:
ヘッダーは、
現在の要求の特徴集合にある特徴が存在するかしないかを示すものです >>1。
[4] Accept-Features:
ヘッダーの値は、
0個以上の値のリスト (#
) です >>1。
[5] それぞれの値は特徴タグなどを使った式と、0個以上の引数です >>1。
[7] ただし引数は拡張用で未定義 >>1 とされています。
[13] 式は、特徴タグか、 !
と特徴タグか、
特徴タグと値を =
または !=
で連結したものか、 特徴タグと {
...}
で括った値を =
で連結したものか、 *
のいずれかです。 >>1
[14] 特徴タグのみの指定は、存在することを表します >>1。
[15] !
は、その特徴タグが存在しないことを表します >>1。
[16] =
と値は、その特徴タグと値が存在することを表します。
値が {
...}
で括られている場合は、
それ以外の値では存在しないことを表します。 >>1
[17] !=
と値は、その特徴タグが存在するものの、
その値ではないことを表します。 >>1
[18] *
は、このヘッダーで特徴集合すべてを説明しきっていないことを表します。
言及されていない特徴タグが含まれるかもしれませんし、
{
...}
が使われていない特徴タグには他の値があるかもしれません。 >>1
[12] 鯖は遠隔異体選択アルゴリズムで使うことができます >>1。
[2] RFC 2295 (HTTP 透過内容折衝) 8.2 Accept-Features
The Accept-Features request header can be used by a user agent to give information about the presence or absence of certain features in the feature set of the current request. Servers can use this information when running a remote variant selection algorithm.
Accept-Features
要求頭は、
利用者エージェントが現在の要求の特注集合中のある特徴があるかないかについての情報を与えるために使うことが出来ます。
サーバーは、遠隔変種選択算法を動作させる時にこの情報を使うことが出来ます。
Note: the name `Accept-Features' for this header was chosen because of symmetry considerations with other Accept- headers, even though the Accept-Features header will generally not contain an exhaustive list of features which are somehow `accepted'. A more accurate name of this header would have been `Feature-Set-Info'.
注意 : Accept-Features
というこの頭の名前は、
他のAccept‐頭との整合性のために選ばれましたが、
Accept-Features
頭は通常はともかく「受け入れる」
特徴の完璧な目録を含みはしません。
この頭のもっと正確な名前は Feature-Set-Info
辺りだったでしょう。
Accept-Features = "Accept-Features" ":" #( feature-expr *( ";" feature-extension ) ) feature-expr = [ "!" ] ftag | ftag ( "=" | "!=" ) tag-value | ftag "=" "{" tag-value "}" | "*" feature-extension = token [ "=" ( token | quoted-string ) ]
No feature extensions are defined in this specification. An example is:
Accept-Features: blex, !blebber, colordepth={5}, !screenwidth, paper = A4, paper!="A2", x-version=104, *
The different feature expressions have the following meaning:
- ftag
- ftag is present
- !ftag
- ftag is absent
- ftag=V
- ftag is present with the value V
- ftag!=V
- ftag is present, but not with the value V
- ftag={V}
- ftag is present with the value V, and not with any other values
- *
- the expressions in this header do not fully describe the feature set: feature tags not mentioned in this header may also be present, and, except for the case ftag={V}, tags may be present with more values than mentioned.
各特徴式は次の意味を持ちます。
ftag
!ftag
ftag=V
ftag!=V
ftag={V}
*
ftag={V}
の場合を除き、示されている値以外もあるかもしれない。Absence of the Accept-Features header in a request is equivalent to the inclusion of
- Accept-Features: *
By using the Accept-Features header, a remote variant selection algorithm can sometimes determine the truth value of a feature predicate on behalf of the user agent. For example, with the header
Accept-Features: blex, !blebber, colordepth={5}, !screenwidth, paper = A4, paper!="A2", x-version=104, *the algorithm can determine that the following predicates are true:
blex, colordepth=[4-], colordepth!=6, colordepth, !screenwidth, paper=A4, colordepth=[4-6]and that the following predicates are false:
!blex, blebber, colordepth=6, colordepth=foo, !colordepth, screenwidth, screenwidth=640, screenwidth!=640,but the truth value of the following predicates cannot be determined:
UA-media=stationary, UA-media!=screen, paper!=a0, x-version=[100-300], x-version=[200-300], x-version=99, UA-media=screen, paper=A0, paper=a4, x-version=[100-199], wuxta
[10] RFC 4229 は RFC 2295 を出典にIANA登録簿に状態「実験的」で登録しています >>9。
[20] draft-ietf-fax-smtp-capabilities-00 - SMTP Service Extension for Capabilities Exchange ( ( 版)) <https://tools.ietf.org/html/draft-ietf-fax-smtp-capabilities-00>
;
の前後に OWS、=
の前後に BWS が挿入されると推測されます。