[17] Allow:
ヘッダーは、
対象資源で使うことができる要求メソッドの一覧を表しています。
[5] Allow:
ヘッダーは、対象資源が対応していると広告される要求メソッドの一覧を表しています
>>4。
[9] なお、 Allow:
ヘッダーの値はその時点で鯖が認めると考える要求メソッドの一覧であって、
その後の任意の時点で同じく認められているという保証はありません。
認められる要求メソッドは時間の経過とともに変化しても構いません。
[6] このヘッダーの値は、要求メソッド名の0個以上のリスト
(#
) です >>4。
[11] 空の Allow:
ヘッダーは、どの要求メソッドも認められないことを表します。
これは設定によって一時的に資源が無効化されているときに起こり得ます。 >>4
[406] 起源鯖は、 405
応答で Allow:
ヘッダーを生成しなければなりません >>4, >>19。
[8] 起源鯖は、それ以外でも Allow:
ヘッダーを生成して構いません
>>4。
[407] 501
応答で Allow:
ヘッダーが使われることがありますが、必須とはされていません。
[212] 鯖は、 OPTIONS
要求に対して成功の応答を帰す場合には、
鯖が実装していて対象資源に適用できるオプション機能を示すヘッダー
(例えば Allow:
) を送信するべきです
>>206。
[28] Web Annotation Protocol >>27 は応答で Allow:
を使うことを要求しています。 200
応答のみならず、
201
応答で使った例も示されています。 201
応答で指定された場合 Location:
で示された作成された資源に関する表明を意図していると推測されますが、
明記はされていません。
[14] 串は Allow:
ヘッダーを変更してはなりません
>>4。
[21] クライアントが Allow:
をどう使うべきなのか、
どのような利用法があるのかは明確ではありません。
要求メソッドを変えると要求の意味が変わってしまいますから、
普通は自動的に変更することはできません。クライアントの開発者に対するエラーの修正のヒントとして使うべきものなのでしょう。
Allowed:
ヘッダー[1] HTTP92 では、 Allow:
という記述と
Allowed:
という記述が混じっています >>25。
[26] RFC 4229 は HTTP92 も出典の1つにしていますが、
Allowed:
はIANA登録簿に登録されていません。
[502] RFC 3507 - Internet Content Adaptation Protocol (ICAP) ( ( 版)) <http://tools.ietf.org/html/rfc3507#page-14>
[503] RFC 3507 - Internet Content Adaptation Protocol (ICAP) ( ( 版)) <http://tools.ietf.org/html/rfc3507#section-4.6>
[3] Allow
に PATCH
が含まれる場合、
Accept-Patch
頭欄も応答に含めるべきです
RFC 5789。
[22] CORS では Allow:
ではなく、
Access-Control-Allow-Methods:
が使われます。
Allow:
の記述と実際に認められる要求メソッドが違っている可能性もあります。 もっともそのような実装は HTTP に適合しているとは言いがたく、 不具合というべきでしょう。 (Allow:
を返した直後に認められる要求メソッドが変化したと主張することはできますが、 常識的にはそのような主張を認めるべきではないでしょう。)