94

The HTTP OPTIONS method is supposedly used to determine what other methods the server supports on a given resource. Given that, I have two questions:

  • What does this response look like? I have seen examples with CSV lists in Public, Allow, and even Access-Control-Allow-Methods headers. Are they all needed? What's the difference? RFC 2616 doesn't seem to be very helpful here.

  • Would it be appropriate to use this to list the actions that a resource supports in a non-REST-API environment? For example, if my ConversionController supports the action convert, would a response like this make sense:

Request:

OPTIONS /conversion HTTP/1.1

Response:

HTTP/1.1 200 OK
...
Allow: CONVERT
...
4

3 に答える 3

23

RFC 2616 は「許可」を定義しています ( http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.7 )。「パブリック」は使用されなくなりました。「Access-Control-Allow-Methods」は CORS 仕様で定義されています ( http://www.w3.org/TR/cors/を参照)。

于 2012-08-13T07:59:49.267 に答える
9

タイトルに応じて: 「HTTP OPTIONS リクエストに応答するにはどうすればよいですか?」それに答えるために、OPTIONSリクエストに応答したい理由を知りたいですか? OPTIONS リクエストを送信しているのは誰/何ですか? なぜですか? 多くの公開サーバーは、何らかの形式の「エラー」または「許可されていません」 (500、501、405) で応答します。したがって、クライアントが合理的に OPTIONS リクエストを送信し、有用で意味のある情報 (WebDAV、CORS など) が返されることを期待する特定の状況にない限り、おそらく「それはしないでください」と応答する必要があります。

「OPTIONS /conversion HTTP/1.1」リクエストに関する質問に関しては、サーバーのクライアントが存在することがわかっている場合を除き、「/conversion」に OPTIONS リクエストを送信し、「Allow: CONVERT」の応答を期待するクライアントが存在することがわかっている場合を除きます。 、」答えはノーです。そのように答えるのは意味がありません。OPTIONS をサポートし、「許可」で応答するほとんどの実装は、標準の HTTP メソッドで応答すると思います。

これはトピックに関する素晴らしい記事です。

概要: OPTIONS はキャッシュをサポートしていないため、すぐに問題になります。代替手段: サーバー全体のメタデータ:既知の URI を試してください。リソース固有:その応答でLink ヘッダーを使用するか、そのリソースの表現形式のリンクを使用してみてください。

最後に、サービスの説明が必要な場合は、WADLまたはRSDLをご覧ください。

編集：

dotnetguy は、次のコメントで適切な点を指摘しています。OPTIONS は、特定のコンテキスト (CORS など) では間違いなく価値があります。もちろん、別に提案するつもりはありませんでした。

于 2014-08-21T06:08:31.540 に答える