HTTP OPTIONSリクエストに応答する方法は？

Question 1

HTTPOPTIONSメソッドは、サーバーが特定のリソースでサポートする他のメソッドを決定するために使用されると思われます。それを考えると、私は2つの質問があります：

この応答はどのように見えますか？私は、中にCSVリストで例を見てきたPublic、AllowとさえAccess-Control-Allow-Methodsヘッダ。それらはすべて必要ですか？違いは何ですか？ RFC 2616は、ここではあまり役に立たないようです。
これを使用して、リソースが非REST-API環境でサポートするアクションを一覧表示するのは適切でしょうか？たとえば、私ConversionControllerがアクションをサポートしている場合、次のconvertような応答は意味がありますか？

リクエスト：

OPTIONS /conversion HTTP/1.1

応答：

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

Question 2

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

Question 3

タイトルへの応答：「HTTPOPTIONSリクエストに応答する方法は？」それに答えるために、なぜあなたがOPTIONSリクエストに応答したいのか知りたいですか？OPTIONSリクエストを送信しているのは誰/何ですか。その理由は何ですか。多くのパブリックサーバーは、何らかの形の「エラー」または「許可されていません」（500、501、405）で応答します。したがって、クライアントがOPTIONSリクエストを合理的に送信し、有用で意味のある情報（WebDAV、CORSなど）が返されることを期待する特定の状況でない限り、「そうしないでください」と応答することをお勧めします。

「OPTIONS / ConversionHTTP / 1.1」リクエストに関する質問について：サーバーのクライアントが存在することがわかっていない限り、「/ convert」にOPTIONSリクエストを送信し、「Allow：CONVERT」の応答を期待するクライアント、」答えはノーです。そのように応答するのは意味がありません。私はほとんどの実装だと思いやるとサポートオプションおよび応答「は、許可」の標準的なHTTPメソッドで応答します。

これは、このトピックに関するすばらしい記事です。

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

最後に、求めているのがサービスの説明である場合は、WADLまたはRSDLを参照してください。

編集：

dotnetguyは、以下のコメントで良い点を示しています。OPTIONSは、特定のコンテキスト（CORSなど）で間違いなく価値があります。私は確かに他のことを提案するつもりはありませんでした。

Question 4

HTTP OPTIONSリクエストとは何ですか？

のように、サーバーができるようになりますどのようなHTTPメソッドを知るために、クライアントからの要求であるGET、POSTなど、

リクエスト

特定のリソースのオプションについて尋ねると、リクエストは次のようになります。

OPTIONS /index.html HTTP/1.1

または一般的にサーバーについて尋ねるときは次のようになります。

OPTIONS * HTTP/1.1

応答

応答にはAllow、許可されたメソッドを含むヘッダーが含まれます。

Allow: OPTIONS, GET, HEAD, POST

サーバーがHTTPOPTIONSリクエストを受信するのはなぜですか？

一部のRESTAPIはそれを必要とします（ただし、APIを定義している場合は、それを知っているでしょう）
ブラウザは、サーバーがCORSを理解しているかどうかを確認するために、「プリフライト」リクエストとしてサーバーに送信します。
攻撃者はAPIに関する詳細情報を入手するために送信します