[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登録簿に登録されていません。
The Allow entity-header field lists the set of methods supported by the resource identified by the Request-URI. The purpose of this field is strictly to inform the recipient of valid methods associated with the resource. The Allow header field
{1945} is not permitted in a request as part of a POST entity{2068〜} MUST be present in a 405 (Method Not Allowed) response.
Allow
実体頭欄は、 Request-URI
で識別される資源が対応している method
の集合を列挙します。この欄の目的は、
その資源に関連付けられた妥当な method
を受信者に厳密に通知することです。
Allow
頭欄は、 {1945} 要求の POST 実体の一部としては認めません。 {2068〜} 405
(Method 不認可) 応答中に出現しなければなりません。
{〜2068} Allow = "Allow" ":" 1#method- {2616} Allow = "Allow" ":" #Method
>Example of use: 使用例 : > - Allow: GET, HEAD, PUT {2068}
This field cannot prevent a client from trying other methods. However, the indications given by the Allow header field value
{1945} should{2068} SHOULD be followed. The actual set of allowed methods is defined by the origin server at the time of each request.
この欄は、クライアントアが他の method
を試行することを防ぐことは出来ません。
しかし、 Allow
頭欄値による標示には従うべきです。
認められる method の実際の集合は、各要求の時点起源サーバーにより定義されます。
> {2068〜} The Allow header field MAY be provided with a PUT request to recommend the methods to be supported by the new or modified resource. The server is not required to support these methods and SHOULD include an Allow header in the response giving the actual supported methods.
Allow
頭欄は、新規のまたは修正済みの資源が対応している
method を推奨するために PUT
要求で提供しても構いません。
サーバーはそれらの method に対応する必要はありませんし、
応答中の Allow
頭には実際に対応している
method を含めるべきです。
A proxy
{1945} must not{2068} MUST NOT modify the Allow header field even if it does not understand all the methods specified, since the user agent{1945} may{2068} MAY{2616} might have other means of communicating with the origin server.
串は、指定された全ての method
を理解しないとしても、 Allow
頭欄を修正してはなりません。
利用者エージェントはもしかすると起源サーバーと通信する他の手段を持っているかもしれないからです。
{〜2068} The Allow header field does not indicate what methods are implemented
{1945} by{2068} at the server {2068} level. {2068} Servers MAY use the Public response-header field (section 14.35) to describe what methods are implemented on the server as a whole.
Allow
頭欄は、サーバー段階でどの method
が実装されているかは示しません。サーバーは、
サーバー全体としてどの method を実装しているかを記述するのに、
Public
応答頭欄を使っても構いません。
[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:
が使われます。
The response must have an Allow header that lists the HTTP methods available for interacting with the Annotation [rfc7231].
Allow:
の記述と実際に認められる要求メソッドが違っている可能性もあります。 もっともそのような実装は HTTP に適合しているとは言いがたく、 不具合というべきでしょう。 (Allow:
を返した直後に認められる要求メソッドが変化したと主張することはできますが、 常識的にはそのような主張を認めるべきではないでしょう。)