[49] Prefer:
ヘッダーは、要求の処理方法に関するクライアントの好みを示すものです >>7。
[15] Prefer:
ヘッダーは、
クライアントが鯖の特定の動作を好んでいること、
しかしそれは要求の成功には必須ではないことを示すために使います >>7。
[16] Prefer:
ヘッダーの値は、1つ以上の「好み」
のリスト (#
) です >>7。
[19] 好みは、好み字句に、省略可能な値と、0個以上の引数を続けたものです。
値を指定する場合は、 =
を字句と値の間に置きます。
また各引数の前には ;
を置きます。 >>7
[29] 好み字句は、字句です。大文字・小文字不区別です。 >>7
[35] 同名の好み字句を複数回指定するべきではありません >>7。
[24] 引数は、名前か、名前と値を =
で連結したものです >>7。
[26] 引数の名前は、字句です。大文字・小文字不区別です。 >>7
[20] ただし引数のかわりに空文字列とすることができます >>7。
[30] 引数の意味は好み字句に依存します。引数の順序は意味を持ちません。 >>7
[21] ;
の前後には OWS を挿入できます。また =
の前後には BWS があります。 >>7
[46] 字句と引用文字列のどちらの構文を使っても構わず、 どちらも同じ意味と思われますが、明記はされていません。また好み字句それぞれの構文の定義で値が字句または引用文字列のどちらかの構文だけが示されていることがありますが、 HTTP の仕様では歴史的にどちらでも構わないものと (行間から) 解釈されています。
[25] 鯖は、好み字句を認識できない場合や従えない場合には、誤りを通知するのではなく、 当該字句を無視して処理を継続しなければなりません >>7。
[39] 鯖は同名の好み字句が複数回指定されていれば、誤り通知その他の通常と異なる処理をすることなく、最初のもの以外は無視するべきです >>7。
[31] 串は、 Connection:
で明示されない限り、
Prefer:
を転送しなければなりません >>7。
[32] 串は起源鯖とは別に Prefer:
を受けて処理しても構いません
>>7。
respond-async
を参照。[41] 応答のキャッシュに影響を及ぼす形で Prefer:
を使わないよう注意することがすすめられています >>7。
Prefer:
の指定 (またはその欠如) が応答のキャッシュに影響を及ぼすなら、
Vary: Prefer
または Prefer: *
を指定しなければなりません >>7。
Upgrade-Insecure-Requests:
は当初
Prefer:
を使うことを計画していましたが、
撤回されました (Upgrade-Insecure-Requests:
参照)。
しかしそんな具合では、HTTPキャッシュが使われ得る場面で Prefer:
ヘッダーはほとんど使いものにならないということになりますね。[44] Prefer:
ヘッダーで指定するリスト項目それぞれの字句は好み字句 >>7
と呼ばれています。またそれぞれの項目 (あるいは好み字句によって表される概念) のことは好み >>7 と呼ばれています。
[48] 好み字句としては次のようなものが定義されています。
[45] 好み字句には IANA登録簿があります >>7, >>50。
[43] RFC 7240 には priority
という架空の好み字句の例 >>7
も示されています。
[58] >>57 に JSON 形式の好み字句一覧があります。
[62] RFC 723x と同時に出版された RFC 7240 により導入されました。
[52] OData は Prefer:
をプロトコルに組み込んでいます。
[53] ただし OData が独自に追加した好みは現時点で IANA に登録されていません。
[61] Prefer:Safe
は Webブラウザーや Webアプリケーションで多数の実装例があります。
その他の機能が実装されているのかは不明です。
[10] Expect:
ヘッダーの元々の定義も似たようなものでしたが、
Expect:
の場合すべての中間器と起源鯖がすべての「期待」
に対応していなければ拒絶しなければならないことになっており、
対応していてもいなくても良いクライアントの「好み」には相応しくないとして
Prefer:
が別途追加されました >>7。
鯖は Prefer:
で指定された「好み」を無視することができます >>7。
[14] Opt:
ヘッダーも似たような要件で追加されたようですが、
名前空間により間接的に要望を記述するものとなっていますので、
直接指定する Prefer:
とは異なっています。
[11] 要求URL の query に「好み」を指定することもできますが、
URL を変更するとキャッシュに悪影響があるなど相応しくないとして、
Prefer:
が別途追加されました >>7。
[12] Prefer:
で指定する値として規定・提案されているもののうちのいくつかは、
URL の query や POST
時の application/x-www-form-urlencoded
や multipart/form-data
や application/json
などの payload body に (アプリケーション依存の方法で) 指定するので十分な気がしますが・・・。
[13] あるいは Prefer:
ヘッダーにまとめずとも、
用途ごとにそれぞれ個別のヘッダーとした方が処理もしやすそうなものがいくつかありますが・・・。
[56] JSON Home Document では、 accept-prefer
により鯖が対応できる好み字句を表明できます。
[418] Create Table ( ( 版)) <http://msdn.microsoft.com/ja-jp/library/azure/dd135729.aspx>