Allowed

Allow: ヘッダー (HTTP)

[17] Allow: ヘッダーは、 対象資源で使うことができる要求メソッドの一覧を表しています。

[18] このヘッダー405 応答などで用いられます。

仕様書

意味

[5] Allow: ヘッダーは、対象資源が対応していると広告される要求メソッドの一覧を表しています >>4

[9] なお、 Allow: ヘッダーの値はその時点でが認めると考える要求メソッドの一覧であって、 その後の任意の時点で同じく認められているという保証はありません。 認められる要求メソッドは時間の経過とともに変化しても構いません。

[10] また Allow: の記述と実際に認められる要求メソッドが違っている可能性もあります。 もっともそのような実装は HTTP に適合しているとは言いがたく、 不具合というべきでしょう。 (Allow: を返した直後に認められる要求メソッドが変化したと主張することはできますが、 常識的にはそのような主張を認めるべきではないでしょう。)

構文

[6] このヘッダーの値は、要求メソッド名の0個以上のリスト (#) です >>4

  1. ?
    1. メソッド名
    2. *
      1. OWS
      2. ,
      3. OWS
      4. メソッド名

[11] 空の Allow: ヘッダーは、どの要求メソッドも認められないことを表します。 これは設定によって一時的に資源が無効化されているときに起こり得ます。 >>4

[12] 複数 Allow: ヘッダーがある場合、 そのいずれもが空の場合を指していると推測されます。
[13] GETHEAD実装が要求されていますが、対象資源が対応している必要はなく、 どの要求メソッドに対しても 405 を返すことはあり得るようです。

文脈

[406] 起源鯖は、 405 応答Allow: ヘッダー生成しなければなりません >>4, >>19

[20] これは実際には守られていないこともあるようです。

[8] 起源鯖は、それ以外でも Allow: ヘッダー生成して構いません >>4

[407] 501 応答Allow: ヘッダーが使われることがありますが、必須とはされていません。

[212] は、 OPTIONS 要求に対して成功の応答を帰す場合には、 が実装していて対象資源に適用できるオプション機能を示すヘッダー (例えば Allow:) を送信するべきです >>206

[7] このヘッダーは、複数個指定できます。

[24] RFC 2616 までは PUT 要求でも認められていましたが、 RFC 7231 で削除されました >>23

[28] Web Annotation Protocol >>27応答Allow: を使うことを要求しています。 200 応答のみならず、 201 応答で使った例も示されています。 201 応答で指定された場合 Location: で示された作成された資源に関する表明を意図していると推測されますが、 明記はされていません。

処理

[14] Allow: ヘッダーを変更してはなりません >>4

[15] 要求メソッドに関わらない一般的な方法でメッセージを処理できますから、 「対応する要求メソッド」という概念が存在していません。

[21] クライアントAllow: をどう使うべきなのか、 どのような利用法があるのかは明確ではありません。 要求メソッドを変えると要求の意味が変わってしまいますから、 普通は自動的に変更することはできません。クライアントの開発者に対するエラーの修正のヒントとして使うべきものなのでしょう。

歴史

Allowed: ヘッダー

[1] HTTP92 では、 Allow: という記述と Allowed: という記述が混じっています >>25

[2] 歴史的には Allow: が正しいです。

[26] RFC 4229HTTP92 も出典の1つにしていますが、 Allowed:IANA登録簿に登録されていません。

RFC

[16] RFC 1945 (HTTP/1.0) 10.1; RFC 2068 (HTTP/1.1) 14.7 Allow

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] AllowPATCH が含まれる場合、 Accept-Patch 頭欄応答に含めるべきです RFC 5789

[22] CORS では Allow: ではなく、 Access-Control-Allow-Methods: が使われます。

[29] Web Annotation Protocol () <https://w3c.github.io/web-annotation/protocol/wd/#h-annotation-retrieval>

The response must have an Allow header that lists the HTTP methods available for interacting with the Annotation [rfc7231].