[25] A-IM: は、クライアントが対応しており、希望する実現値操作とその適用順序を指定するものです。
本項は歴史的事項を説明しています。本項の内容の一部または全部は、現在の状況とは異なるかもしれません。
(なお本項の内容の一部または全部は、互換性または歴史的連続性のために現在も有効な場合もあります。しかし新たに利用することは避けるべきです。)
[5] A-IM: ヘッダーの値は、
実現値操作の指定と省略可能な q 引数の0個以上のリストです。
>>3
[7] q 引数を指定する場合、直前に ;
が必要です >>3。
仕様書の時代的に構文上明記されていませんが、 ;
の前後には OWS を挿入できると考えられます。
[6] q は、大文字・小文字不区別です >>3。
[9] A-IM: ヘッダーに差分符号化が含まれる場合は、
If-None-Match: ヘッダーに当該要求URL
に対する以前の応答から得た1つ以上の実体タグを含めなければなりません
>>3。
[12] A-IM: に示されている実現値操作は、そのq値が0でない限り、
受け入れられます。鯖は A-IM:
に示されていない恒等でない実現値操作を使ってはなりません。 >>3
[14] 恒等 (identity) は、 q値が 0 と明示されない限り、
常に受け入れられます >>3。
[15] 受け入れられる実現値操作が複数ある時は、 A-IM:
ヘッダーの指定順に適用しなければなりません >>3。
[13] 受け入れられる実現値操作が複数あり、それらに互換性がなければ、 q値が最高のものを採用します。 >>3
[1] 鯖は、 A-IM: ヘッダーに差分符号化が指定された場合、
他のいくつかの条件を満たせば、差分符号化した応答を返さなければなりません
>>2。
[11] 鯖は、 A-IM: が指定されていて、
受け入れられる実現値操作の応答を返せない時は、
406 応答を返すべきです >>3。
[16] 鯖が実現値操作を適用するかどうかの選択は、 後から2入力実現値操作を適用するかの選択と独立であるべきです >>3。
[17] 例えば
A-IM: vcdiff, diffe, gzip
... は、差分符号化 vcdiff や diffe と、
圧縮 gzip を受け入れることを示しています。
鯖は diffe の後に gzip
を適用するのは有用であるが、 vcdiff の後に
gzip を適用するのは有用ではない (ので適用しない)
と判断することができます >>3。しかしクライアントがそれを指定する方法は用意されておらず、
単に3つの実現値操作へ対応していることと、適用の順序を記述しているに過ぎません。
[18] 鯖は gzip のみ適用することも認められていますし、
実現値操作を1つも適用しないこともできます。
[19] 形式的には vcdiff の後に diffe
を適用することも認められていますが、 diffe
は2入力の実現値操作ですから、 vcdiff
の結果出力が1つになっていると適用できません。 (q値が異なれば >>13
より高い方が採用されるのでしょう。q値が同じ場合どちらを選ぶべきなのかは仕様上規定がありません。)
[21] 同じ値を複数指定することは禁止されていませんし、
複数指定された場合の解釈も明記されていません。
圧縮は同じ方法を複数適用することも可能で、
A-IM: gzip, diffe, gzip
のような指定には意味があるかもしれません。
[22] range を複数指定すると Range:
や Content-Range: は1回しか指定できないのでどう指定・解釈したらいいのかわからなくなります。
[20] RFC 3229 (差分符号化) 10.5.3 A-IM
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.
A-IM 要求頭欄は、 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.
A-IM 要求頭欄が一つ以上の差分符号化値を含む時、
要求は 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:
鯖は (使用することのできるもののうちの) ある実現値操作が受入れ可能かを、
与えられた 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".
A-IM 欄に列せられていれば、
qvalue が 0 とされていない限り、
受入れ可能です。 (HTTP/1.1 仕様書の3.9節で定義されている通り、
qvalue 0 は「受入れ不能」を意味します。)
鯖は実現値操作が要求の A-IM 頭に列せられていない限り応答に非同一実現値操作を使用してはなりません。qvalue を持つ受入れ可能実現値操作を優先します。identity 実現値操作は、 A-IM
欄が 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.
要求に A-IM 欄が存在し、鯖が A-IM
頭に従い受入れ可能な応答を送信できない場合には、
鯖は 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.
応答が複数の実現値操作を使用する時は、
実現値操作は 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.)
鯖が実現値操作を適用するかどうかについての選択は、
応答にどの二入力実現値操作を次に適用するかの選択とは独立とするべきです。
(二入力実現値操作は差分符号化も含みます。差分符号化は二つの異なる値を入力として取りますから。圧縮と 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:
A-IM: vcdiff, gdiff
This example means that the client will accept a delta encoding in either vcdiff or gdiff format.
この例はクライアントが vcdiff 書式または
gdiff 書式のいずれかの差分符号化を受入れることを意味します。
A-IM: vcdiff, gdiff;q=0.3
This example means that the client will accept a delta encoding in either vcdiff or gdiff format, but prefers the vcdiff format.
この例はクライアントが vcdiff 書式または
gdiff 書式のいずれかの差分符号化を受入れるものの
vcdiff を優先することを意味します。
A-IM: vcdiff, diffe, gzip
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.
この例はクライアントが vcdiff 書式または
diffe 書式のいずれかの差分符号化を受入れ、
gzip で圧縮された差分符号化の出力を受入れることを意味します。
A-IM は diffe が使用された時にだけ
gzip を使うことを主張する方法は提供していませんから、差分符号化されていなくても 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).
有用な受入れ可能な実現値操作 (例えば、 diffe
の後に gzip は有用であるが、
vcdiff の後に gzip はたぶん有用ではない。)
を選択することは鯖実装者に委ねます。
[28] A-IM: feed も参照。
qという名前の引数は禁止されており、曖昧なくA-IM:ヘッダーのq引数と区別できます。 なお類似した構造のAccept:ヘッダーとは違って、q以外にA-IM:ヘッダーに属する引数はなく、q引数が指定されるなら必ず最後の引数となります。