[14] Prefer: handling は、
鯖の誤りからの回復処理に関するクライアントの希望を示すものです。
仕様書
- [3] RFC 7240 - Prefer Header for HTTP ( 版) https://tools.ietf.org/html/rfc7240#section-4.4
- [1] RFC 7240 - Prefer Header for HTTP ( 版) https://tools.ietf.org/html/rfc7240#section-2.1
意味
[4] handling は、クライアントが鯖に対して、
要求の処理中に誤り条件に遭遇した際にどう処理してほしいかを示すものです >>3。
[5] 例えば要求の payload にわずかに構文上や意味上の誤りがあり、
それでも鯖は処理を成功させられる場合に、
鯖は 4xx 応答を返すか処理を続けるかを
handling を参考に決めることができます >>3。
構文
[6] handling には値として strict
か lenient を指定します。引数はありません。 >>3
[7] 値は大文字・小文字不区別です >>3。
処理モデル
[12] handling=strict と handling=lenient
は排他的で、同時に両方指定することはできません。両方指定されている場合は、
どちらも指定されていないものとして扱うことができます。 >>3
[13] Prefer: 全体の処理モデルにより好み字句の重複は最初のもの以外無視されることになっているのと矛盾する気もしますが。。。[15] どのような誤りが対象となっているのか仕様上明記されていません。
HTTP その他の仕様上要求されている誤りを handling=lenient
により無視して良いのか、あるいは HTTP その他の仕様上要求されている誤りからの回復方法を
handling=strict により無視して良いのかは明らかではありません。
[16] 例えば HTTP/1.1 鯖は Host: ヘッダーがない要求に
400 を返すことになっていますが、 Prefer: handling=lenient
が指定されていたとしても処理を続けて良いとは思えません。
handling=strict
[8] handling=strict は、
要求に誤りが含まれていれば鯖がそれを拒絶することをクライアントが望んでいることを示します
>>3。
[9] もっとも鯖はそれに従う義務はなく、誤りから回復しても構いません >>3。
handling=lenient
[10] handling=lenient は、
要求に誤りが含まれていても鯖がそれを処理することをクライアントが望んでいることを示します
>>3。
[11] もちろん鯖はそれに従う義務はなく、誤りを表す応答を返しても構いません。
関連
[17] OData は handling=lenient
を使わないで独自の odata.continue-on-error を使っています。
メモ
[2] RFC 7240 には Prefer: Lenient という例が示されています >>1 が、
handling=lenient の誤りと思われます。