8

RFC には次のように記載されています。

10.4.6 405メソッドは許可されていません

Request-URI で識別されるリソースに対して、Request-Line で指定されたメソッドは許可されていません。応答には、要求されたリソースの有効なメソッドのリストを含む Allow ヘッダーが含まれている必要があります。

ただし、その MUST に準拠する単一のサーバーを特定できませんでした。

さまざまなプロキシや動的アプリケーションなどが存在することを考えると、最新の Web サーバーでその要件を満たすのは非常に難しいことがわかります。

  1. なぜ、歴史的に、その要件は理にかなっているのですか?
  2. その動作に依存するものはありますか？そのユースケースは何ですか？
  3. httpのこの側面を「適切に」実装するWebサーバーはありますか? 私の知る限り、IIS (少なくとも ASP.NET を使用している場合) や一部の "RESTful" API でさえ、偽のメソッドを指定すると 405 ではなく 404 を返します。

さらに、BOGUS など、明らかにサーバーによって実装されていないメソッドに対して、サーバーが 405 を返すのはなぜですか?

HTTP のこれらの部分は、仕様に準拠しているサーバーがあるかどうかを見て、「痕跡」と見なす必要がありますか?

実際、ほとんどのフレームワークが「Allow」を適切に返すことはそれほど難しくありません。私が知っているすべてのフレームワークでは、特定のコントローラーが呼び出されるメソッド (通常はデフォルトで GET) を指定する必要があり、コードは拡張メソッドをフレームワークに簡単に登録して、それを返すことができます。

これまでのところ、証拠は、a) 誰も仕様を読んでおらず、誰もこの要件について知らない、b) 誰もこの機能を気にしていない、のいずれかを示しているようです。

4

1 に答える 1

2

質問に直接答えようとしている：

  1. 特に、Meryn のコメントが HATEOAS API について述べているように、要件は依然として理にかなっています。

  2. サーバーは「応答を返すことによって要求を処理するために接続を受け入れるアプリケーション プログラム」であるため、そう言うのは簡単です。サーバーに依存するアプリケーションがネット上に存在します。;) そのような使用例の 1 つは、リソースが「ファクトリー リソース」ではないことを示すwithに応答405することです。POST /resource/1/Allow: GET, HEAD, PUT, DELETE

  3. リソースで許可されるメソッドはアプリケーション ロジックによって異なる可能性があるため、質問で指摘したように、アプリケーション サーバーも考慮する必要があります。その場合、はい - たとえば、django はresponseを含む適切なAllowヘッダーを405返します。

于 2014-11-09T12:15:35.487 に答える