[49] Prefer: ヘッダー は、要求 の処理方法に関するクライアント の好みを示すものです >>7
仕様書 [7] RFC 7240 - Prefer Header for HTTP
( (2014-06-07 01:59:37 +09:00 版))
http://tools.ietf.org/html/rfc7240 [50] Hypertext Transfer Protocol (HTTP) Parameters (2014-06-13 18:52:05 +09:00 版) http://www.iana.org/assignments/http-parameters/http-parameters.xhtml#preferences 意味 [15] Prefer: ヘッダー は、
クライアント が鯖 の特定の動作を好んでいるprefer こと、
しかしそれは要求 の成功には必須ではないことを示すために使います >>7
[8] PUT 資源 を編集した後に、
変更後の完全な表現 を応答 として得たいこともあれば、
操作が成功したことのみの最低限の応答 を得たいこともあります >>7
[9] 鯖 は、技術的に非妥当 だったり誤っていたりするものの理解はできる要求 をどう処理するか決めなければならないことがあります。
鯖 は誤りがあっても要求 を処理できるかもしれませんが、
アプリケーション の要件と要求 の性質によってはそれが好ましかったり、
好ましくなかったりするかもしれません。 >>7
[42] Prefer: 内容折衝 の仕組みとして使うべきではありません >>7
構文 [16] Prefer: ヘッダー の値は、1つ以上の「好み」
のリスト (#) です >>7
好み *OWS , OWS 好み [19] 好みは、好み字句 に、省略可能な値と、0個以上の引数 を続けたものです。
値を指定する場合は、 = 字句 と値の間に置きます。
また各引数 の前には ; >>7
[29] 好み字句 は、字句 です。大文字・小文字不区別 です。 >>7
字句 ?= |字句 引用文字列 *OWS ; ?OWS 引数 [35] 同名の好み字句 を複数回指定するべきではありません >>7
[36] なぜ MUST [37] 別名の好み字句 の順序は意味を持ちません >>7
[24] 引数 は、名前か、名前と値を = >>7
[26] 引数 の名前は、字句 です。大文字・小文字不区別 です。 >>7
字句 ?= |字句 引用文字列 [20] ただし引数 のかわりに空文字列 とすることができます >>7
[30] 引数 の意味は好み字句 に依存します。引数 の順序は意味を持ちません。 >>7
[38] 同名の引数 の処理には RFC は言及していないようです。[21] ; OWS を挿入できます。また = BWS があります。 >>7
[22] 値は字句 または引用文字列 です。
[23] RFC 7240 は RFC 7230 の word RFC 7230 にはありません。文脈から >>22
のように推測されます。[46] 字句 と引用文字列 のどちらの構文を使っても構わず、
どちらも同じ意味と思われますが、明記はされていません。また好み字句 それぞれの構文の定義で値が字句 または引用文字列 のどちらかの構文だけが示されていることがありますが、
HTTP の仕様では歴史的にどちらでも構わないものと (行間から) 解釈されています。
[47] 2014年にもなって未だに行間を読まないといけない仕様書が新たに出版されるとは驚きですが...[27] 好み字句 についても引数 についても、値がないものと、
空文字列 の値は同じです >>7
[28] 次の3つのヘッダー は同じ意味です >>7
Prefer: foo; bar
Prefer: foo; bar=""
Prefer: foo=""; bar [55] これが正しく実装されているかどうかは怪しいところです。要求ヘッダー の場合、
解釈するのは串 、鯖 、WAF などのライブラリー 、個々の
Webアプリケーション のいずれにせよ多数あり、相互運用性 が高い状態を維持するのは困難そうです。
Prefer: safe Webサービス が
Prefer: safe =""相互運用性 が低くなる危険を犯してまでこんな複雑な構文と意味を規定したのでしょうか...)文脈 [17] このヘッダー は要求 で使います。
[18] このヘッダー は複数指定できます。
処理 [25] 鯖 は、好み字句 を認識できない場合や従えない場合には、誤り を通知するのではなく、
当該字句 を無視して処理を継続しなければなりません >>7
[34] Expect: 417 Prefer: [39] 鯖 は同名の好み字句 が複数回指定されていれば、誤り 通知その他の通常と異なる処理をすることなく、最初のもの以外は無視するべきです >>7
[40] なぜか MUST [31] 串 は、 Connection: Prefer: 転送 しなければなりません >>7
[32] 串 は起源鯖 とは別に Prefer: >>7
例えば respond-async [33] しかしその場合に Prefer: [41] 応答 のキャッシュ に影響を及ぼす形で Prefer: すすめられていますurged >>7 Prefer: 応答 のキャッシュ に影響を及ぼすなら、
Vary: Prefer Prefer: *なりません >>7
[60] 実際 Upgrade-Insecure-Requests: Prefer: Upgrade-Insecure-Requests: HTTPキャッシュ が使われ得る場面で Prefer: ヘッダー はほとんど使いものにならないということになりますね。好み字句 [44] Prefer: ヘッダー で指定するリスト 項目それぞれの字句 は好み字句 preference token >>7 好み字句 によって表される概念) のことは好みpreference >>7
[48] 好み字句 としては次のようなものが定義されています。contents-of-related depth-noroot handling https odata.allow-entityreferences odata.callback odata.continue-on-error odata.include-annotations odata.maxpagesize odata.track-changes respond-async return return-content return-no-content safe tls waitPrefer: wait
[54] 現時点で広く実装されているのは Prefer: safe 2014-10-27T10:06:02.600Z [45] 好み字句 には IANA登録簿 があります >>7 , >>50
[43] RFC 7240 には priority という架空の好み字句 の例 >>7
[58] >>57 に JSON 形式の好み字句 一覧があります。[57] data-web-defs/headers.txt at master · manakai/data-web-defs (2014-10-28 05:29:17 +09:00 版) https://github.com/manakai/data-web-defs/blob/master/doc/headers.txt
[51] 引数 については各好み字句 の項を参照。
[64]
Tables and Views — PostgREST devel documentation , 2025-09-19T18:49:54.000Z , 2025-12-02T08:49:21.207Z https://docs.postgrest.org/en/latest/references/api/tables_views.html
歴史 [62] RFC 723x と同時に出版された RFC 7240 により導入されました。
[2] draft-snell-http-prefer-18 - Prefer Header for HTTP
( (2013-10-27 07:56:15 +09:00 版))
http://tools.ietf.org/html/draft-snell-http-prefer-18 [5] RFC 7240 - Prefer Header for HTTP
( (2014-06-07 01:59:37 +09:00 版))
http://tools.ietf.org/html/rfc7240 [52] OData は Prefer: プロトコル に組み込んでいます。
[53] ただし OData が独自に追加した好み は現時点で IANA
に登録されていません。 2014-10-27T09:53:00.200Z
[6] 2.2.5.9 Prefer
( (2014-07-25 04:45:16 +09:00 版))
http://msdn.microsoft.com/en-us/library/hh537533.aspx [1] OData Version 4.0 Part 1: Protocol
( (2013-08-14 16:00:00 +09:00 版))
http://docs.oasis-open.org/odata/odata/v4.0/cs01/part1-protocol/odata-v4.0-cs01-part1-protocol.html [4] LDP も Prefer:
[3] Linked Data Platform 1.0
( (2014-03-05 18:42:42 +09:00 版))
http://www.w3.org/TR/2014/WD-ldp-20140311/#h3_prefer-parameters 実装 [61] Prefer:Safe Webブラウザー や Webアプリケーション で多数の実装例があります。
その他の機能が実装されているのかは不明です。
関連 [10] Expect: ヘッダー の元々の定義も似たようなものでしたが、
Expect: 中間器 と起源鯖 がすべての「期待」
に対応していなければ拒絶しなければならないことになっており、
対応していてもいなくても良いクライアント の「好み」には相応しくないとして
Prefer: >>7 鯖 は Prefer: >>7
[14] Opt: ヘッダー も似たような要件で追加されたようですが、
名前空間 により間接的に要望を記述するものとなっていますので、
直接指定する Prefer:
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
( (2014-11-03 07:44:33 +09:00 版))
http://msdn.microsoft.com/ja-jp/library/azure/dd135729.aspx
[59] Upgrade Insecure Requests
(2015-10-07 03:24:10 +09:00 版)
https://w3c.github.io/webappsec-upgrade-insecure-requests/#feature-detect Note: Though the Upgrade-Insecure-Requests header expresses a preference, sending it via the existing Prefer header is problematic, as we expect the response from the server to use it as part of the cache key. Vary: Prefer is too broad, as discussed in w3/webappsec#216.
[63] Web Annotation Protocol
(2017-02-24 02:14:26 +09:00 )
https://w3c.github.io/web-annotation/protocol/wd/#h-annotation-pages The client should not send the Prefer header when requesting the Page, as it has already been taken into account when requesting the Collection.