Edit

Page

Page title:

Page body:

[25] [DFN[[CODE(HTTP)@en[[[A-IM:]]]]]] は、[[クライアント]]が対応しており、希望する[[実現値操作]]とその適用順序を指定するものです。

* 仕様書

[REFS[
- [2] [CITE@en[RFC 3229 - Delta encoding in HTTP]] ([TIME[2014-10-26 21:15:25 +09:00]] 版) <http://tools.ietf.org/html/rfc3229#section-10.3>
- [3] '''[CITE@en[RFC 3229 - Delta encoding in HTTP]] ([TIME[2014-10-26 21:15:25 +09:00]] 版) <http://tools.ietf.org/html/rfc3229#section-10.5.3>'''
]REFS]

* 意味

[4] [CODE(HTTP)@en[[[A-IM:]]]] [[ヘッダー]]は、[[応答]]で受け付けられる[[実現値操作]]を制限するものです [SRC[>>3]]。

* 構文

[5] [CODE(HTTP)@en[[[A-IM:]]]] [[ヘッダー]]の値は、
[[実現値操作]]の指定と省略可能な [CODE(HTTP)@en[[[q]]]] [[引数]]の0個以上の[[リスト]]です。
[SRC[>>3]]

[FIG(railroad)[
= ?
== 値
== *
=== [[OWS]]
=== [CODE(HTTP)[[[,]]]]
=== [[OWS]]
=== 値
]FIG]

[7] [CODE(HTTP)[[[q]]]] [[引数]]を指定する場合、直前に [CODE(HTTP)[[[;]]]]
が必要です [SRC[>>3]]。
仕様書の時代的に構文上明記されていませんが、 [CODE(HTTP)[[[;]]]]
の前後には [[OWS]] を挿入できると考えられます。

[6] [CODE(HTTP)[[[q]]]] は、[[大文字・小文字不区別]]です [SRC[>>3]]。

[FIG(railroad)[
= [[実現値操作]]
= ?
== [[OWS]]
== [CODE(HTTP)[[[;]]]]
== [[OWS]]
== [CODE(HTTP)[[[q]]]]
== [CODE(HTTP)[[[=]]]]
== [[q値]]
]FIG]

;; [8] [[実現値操作]]にも[[引数]]を指定できますが、 [CODE(HTTP)[[[q]]]]
という名前の[[引数]]は禁止されており、曖昧なく [CODE(HTTP)@en[[[A-IM:]]]]
[[ヘッダー]]の [CODE(HTTP)@en[[[q]]]] [[引数]]と区別できます。
なお類似した構造の [CODE(HTTP)@en[[[Accept:]]]] [[ヘッダー]]とは違って、
[CODE(HTTP)@en[[[q]]]] 以外に [CODE(HTTP)@en[[[A-IM:]]]]
[[ヘッダー]]に属する[[引数]]はなく、 [CODE(HTTP)@en[[[q]]]]
[[引数]]が指定されるなら必ず最後の[[引数]]となります。

* 文脈

[9] [CODE(HTTP)@en[[[A-IM:]]]] [[ヘッダー]]に[[差分符号化]]が含まれる場合は、
[CODE(HTTP)@en[[[If-None-Match:]]]] [[ヘッダー]]に当該[[要求URL]]
に対する以前の[[応答]]から得た1つ[[以上]]の[[実体タグ]]を含めなければ[['''なりません''']]
[SRC[>>3]]。

* 処理モデル

[12] [CODE(HTTP)@en[[[A-IM:]]]] に示されている[[実現値操作]]は、その[[q値]]が0でない限り、
受け入れられます。[[鯖]]は [CODE(HTTP)@en[[[A-IM:]]]] 
に示されていない[[恒等]]でない[[実現値操作]]を使っては[['''なりません''']]。 [SRC[>>3]]

[14] [[恒等]] ([CODE(HTTP)@en[[[identity]]]]) は、 [[q値]]が 0 と明示されない限り、
常に受け入れられます [SRC[>>3]]。

[15] 受け入れられる[[実現値操作]]が複数ある時は、 [CODE(HTTP)@en[[[A-IM:]]]]
[[ヘッダー]]の指定順に適用しなければ[['''なりません''']] [SRC[>>3]]。

[13] 受け入れられる[[実現値操作]]が複数あり、それらに互換性がなければ、
[[q値]]が最高のものを採用します。 [SRC[>>3]]

[1] [[鯖]]は、 [CODE(HTTP)@en[[[A-IM:]]]] [[ヘッダー]]に[[差分符号化]]が指定された場合、
他のいくつかの条件を満たせば、[[差分符号化]]した[[応答]]を返さなければ[['''なりません''']]
[SRC[>>2]]。

;; [[差分符号化]]参照。

[11] [[鯖]]は、 [CODE(HTTP)@en[[[A-IM:]]]] が指定されていて、
受け入れられる[[実現値操作]]の[[応答]]を返せない時は、
[CODE(HTTP)[[[406]]]] [[応答]]を返す[['''べきです''']] [SRC[>>3]]。

;; [23] 他の規定との整合性から推測するに、[[恒等]]以外の[[実現値操作]]がどれか1つでも適用可能ならそれを使った[[応答]]を返すべきで、
1つも適用可能でないなら [CODE(HTTP)[[[406]]]] を返すべきなのだと思われます。

[16] [[鯖]]が[[実現値操作]]を適用するかどうかの選択は、
後から[[2入力実現値操作]]を適用するかの選択と独立である[['''べきです''']] [SRC[>>3]]。

[EG[
[17] 例えば
[PRE(HTTP code)[
A-IM: vcdiff, diffe, gzip
]PRE]
... は、[[差分符号化]] [CODE(HTTP)@en[[[vcdiff]]]] や [CODE(HTTP)@en[[[diffe]]]] と、
[[圧縮]] [CODE(HTTP)@en[[[gzip]]]] を受け入れることを示しています。
[[鯖]]は [CODE(HTTP)@en[[[diffe]]]] の後に [CODE(HTTP)@en[[[gzip]]]]
を適用するのは有用であるが、 [CODE(HTTP)@en[[[vcdiff]]]] の後に
[CODE(HTTP)@en[[[gzip]]]] を適用するのは有用ではない (ので適用しない)
と判断することができます [SRC[>>3]]。しかし[[クライアント]]がそれを指定する方法は用意されておらず、
単に3つの[[実現値操作]]へ対応していることと、適用の順序を記述しているに過ぎません。

[18] [[鯖]]は [CODE(HTTP)[[[gzip]]]] のみ適用することも認められていますし、
[[実現値操作]]を1つも適用しないこともできます。

[19] 形式的には [CODE(HTTP)@en[[[vcdiff]]]] の後に [CODE(HTTP)@en[[[diffe]]]]
を適用することも認められていますが、 [CODE(HTTP)@en[[[diffe]]]]
は2入力の[[実現値操作]]ですから、 [CODE(HTTP)@en[[[vcdiff]]]]
の結果出力が1つになっていると適用できません。 ([[q値]]が異なれば >>13
より高い方が採用されるのでしょう。[[q値]]が同じ場合どちらを選ぶべきなのかは仕様上規定がありません。)
]EG]

[21] 同じ値を複数指定することは禁止されていませんし、
複数指定された場合の解釈も明記されていません。
[[圧縮]]は同じ方法を複数適用することも可能で、
[CODE(HTTP)@en[[[A-IM:]] gzip, diffe, gzip]]
のような指定には意味があるかもしれません。

[22] [CODE(HTTP)@en[[[range]]]] を複数指定すると [CODE(HTTP)@en[[[Range:]]]]
や [CODE(HTTP)@en[[[Content-Range:]]]] は1回しか指定できないのでどう指定・解釈したらいいのかわからなくなります。

[24] [[キャッシュ]]の処理に関しては、 [CODE(HTTP)[[[226]]]] を参照。

* 歴史

[FIG(quote)[
[FIGCAPTION[
[20] RFC 3229 (差分符号化) 10.5.3 A-IM
]FIGCAPTION]

> The A-IM request-header field is similar to Accept, but restricts the
instance-manipulations (section 10.1) that are acceptable in the
response.  As specified in section 10.5.2, a response may be the
result of applying multiple instance-manipulations.

[CODE(HTTP)[A-IM]] [[要求頭欄]]は、 [CODE(HTTP)[[[Accept]]]]
と似ていますが、[[応答]]で受入れ可能な[[実現値操作]]を制限します。
10.5.2 節で規定したように、応答は複数の実現値操作を適用した結果かもしれません。

>
-      A-IM = "A-IM" ":" #( instance-manipulation [ ";" "q" "=" qvalue ] )

> When an A-IM request-header field includes one or more delta-coding
values, the request MUST contain an If-None-Match header field,
listing one or more entity tags from prior responses for the
request-URI.

[CODE(HTTP)[A-IM]] 要求頭欄が一つ以上の[[差分符号化]]値を含む時、
要求は [CODE(HTTP)[[[If-None-Match]]]] 頭欄を、
その要求 [[URI]] についての以前の応答からの一つ以上の[[実体札]]を列挙して含めなければ'''なりません'''。

> A server tests whether an instance-manipulation (among the ones it is
capable of employing) is acceptable, according to a given A-IM header
field, using these rules:

鯖は (使用することのできるもののうちの) ある実現値操作が受入れ可能かを、
与えられた [CODE(HTTP)[A-IM]] 頭欄に従って次の規則を使って検査します。

>
- 1. If the instance-manipulation is listed in the A-IM field, then
it is acceptable, unless it is accompanied by a qvalue of 0.
(As defined in section 3.9 of the HTTP/1.1 specification [10],
a qvalue of 0 means "not acceptable.")  A server MUST NOT use a
non-identity instance-manipulation for a response unless the
instance-manipulation is listed in an A-IM header in the request.
- 2. If multiple but incompatible instance-manipulations are
acceptable, then the acceptable instance-manipulation with the
highest non-zero qvalue is preferred.
- 3. The "identity" instance-manipulation is always acceptable,
unless specifically refused because the A-IM field includes
"identity;q=0".

- 実現値操作が [CODE(HTTP)[A-IM]] 欄に列せられていれば、
[CODE(ABNF)[qvalue]] が [CODE(HTTP)[0]] とされていない限り、
受入れ可能です。 (HTTP/1.1 仕様書の3.9節で定義されている通り、
[CODE(ABNF)[qvalue]] [CODE(HTTP)[0]] は「受入れ不能」を意味します。)
鯖は実現値操作が要求の [CODE(HTTP)[A-IM]] 頭に列せられていない限り応答に非同一実現値操作を使用しては'''なりません'''。
- 複数の非互換な実現値操作が受入れ可能な時は、
最高の非零 [CODE(ABNF)[qvalue]] を持つ受入れ可能実現値操作を優先します。
- [CODE(HTTP)[[[identity]]]] 実現値操作は、 [CODE(HTTP)[A-IM]]
欄が [CODE(HTTP)[identity;q=0]] を含めて指定的に拒絶していない限り、
常に受入れ可能です。

> If an A-IM field is present in a request, and if the server cannot
send a response which is acceptable according to the A-IM header,
then the server SHOULD send an error response with the 406 (Not
Acceptable) status code.

要求に [CODE(HTTP)[A-IM]] 欄が存在し、鯖が [CODE(HTTP)[A-IM]]
頭に従い受入れ可能な応答を送信できない場合には、
鯖は [CODE(HTTP)[[[406]]]] (受入れ不能) [[状態符号]]で[[誤り応答]]を送信する'''べきです'''。

> If a response uses more than one instance-manipulation, the
instance-manipulations MUST be applied in the order in which they
appear in the A-IM request-header field.

応答が複数の実現値操作を使用する時は、
実現値操作は [CODE(HTTP)[A-IM]] 要求頭欄に出現した順序で適用しなければ'''なりません'''。

> The server's choice about whether to apply an instance-manipulation
SHOULD be independent of its choice to apply any subsequent two-input
instance-manipulations to the response.  (Two-input instance-manipulations include delta-codings, because they take two different
values as input.  Compression and "range" instance-manipulations take
only one input.  Other instance-manipulations may be defined in the future.)

鯖が実現値操作を適用するかどうかについての選択は、
応答にどの二入力実現値操作を次に適用するかの選択とは独立とする'''べきです'''。
(二入力実現値操作は差分符号化も含みます。差分符号化は二つの異なる値を入力として取りますから。[[圧縮]]と [CODE(HTTP)[range]] の実現値操作は一つの入力だけを取ります。他の実現値操作が将来定義されるかもしれません。)

> Note: the intent of this requirement is to prevent the server from
generating a delta-encoded response that the client can only
decode by first applying an instance-manipulation encoding to its
cached base instance.  A server implementor might wish to consider
what the client would logically have in its cache, when deciding
which instance-manipulations to apply prior to a delta-coding.

注意: この要件は、クライアントが最初にキャッシュした基底実現値に実現値操作符号化を適用しないと復号できない差分符号化応答を鯖が生成してしまうことを防ぐためのものです。鯖実装者はどの実現値操作を差分符号化の前に適用するかを決定する時にクライアントが論理的に何をキャッシュに持っているのかを考慮したいと思うかもしれません。

> Examples:
[PRE[
A-IM: vcdiff, gdiff
]PRE]

> This example means that the client will accept a delta encoding in
either vcdiff or gdiff format.

この例はクライアントが [CODE(HTTP)[[[vcdiff]]]] 書式または
[CODE(HTTP)[[[gdiff]]]] 書式のいずれかの差分符号化を受入れることを意味します。

>
[PRE[
A-IM: vcdiff, gdiff;q=0.3
]PRE]

> This example means that the client will accept a delta encoding in
either vcdiff or gdiff format, but prefers the vcdiff format.

この例はクライアントが [CODE(HTTP)[vcdiff]] 書式または
[CODE(HTTP)[gdiff]] 書式のいずれかの差分符号化を受入れるものの
[CODE(HTTP)[vcdiff]] を優先することを意味します。

>
[PRE[
A-IM: vcdiff, diffe, gzip
]PRE]

> This example means that the client will accept a delta encoding in
either vcdiff or diffe format, and will accept the output of the
delta encoding compressed with gzip.  It also means that the client
will accept a gzip compression of the instance, without any delta
encoding, because A-IM provides no way to insist that gzip be used
only if diffe is used.

この例はクライアントが [CODE(HTTP)[vcdiff]] 書式または
[CODE(HTTP)[diffe]] 書式のいずれかの差分符号化を受入れ、
[CODE(HTTP)[gzip]] で圧縮された差分符号化の出力を受入れることを意味します。
[CODE(HTTP)[A-IM]] は [CODE(HTTP)[[[diffe]]]] が使用された時にだけ
[CODE(HTTP)[gzip]] を使うことを主張する方法は提供していませんから、差分符号化されていなくても [CODE(HTTP)[gzip]] 圧縮を受入れることをも意味します。

> It is left to the server implementor to choose useful combinations of
acceptable instance-manipulations (for example, following diffe by
gzip is useful, but following vcdiff by gzip probably is not useful).

有用な受入れ可能な実現値操作 (例えば、 [CODE(HTTP)[diffe]]
の後に [CODE(HTTP)[gzip]] は有用であるが、
[CODE(HTTP)[vcdiff]] の後に [CODE(HTTP)[gzip]] はたぶん有用ではない。)
を選択することは鯖実装者に委ねます。
]FIG]

[27] [[RFC 4229]] は[[IANA登録簿]]に状態「[[標準]]」で登録しています [SRC[>>26]]。

[REFS[
- [26] [CITE@en[RFC 4229 - HTTP Header Field Registrations]] ([TIME[2014-11-02 18:53:20 +09:00]] 版) <http://tools.ietf.org/html/rfc4229#section-2.1.1>
]REFS]

* メモ

[28] [[A-IM: feed]] も参照。

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Errors

Page name(s)