HTTP OPTIONSリクエストに応答するにはどうすればよいですか？

Question

HTTP OPTIONSメソッドは、サーバーが特定のリソースでサポートする他の方法を決定するために使用されています。それで、2つの質問があります：

• このレスポンスはどのようなものですか？ Public、Allow、さらにはAccess-Control-Allow-MethodsヘッダーのCSVリストの例を見てきました。彼らはすべて必要ですか？違いは何ですか？ RFC 2616はここではあまり役に立ちません。

• これは、リソースが非REST-API環境でサポートするアクションをリストするのに適していますか？例えば、私のConversionControllerアクションconvertを、サポートしている場合だろう、このメイク感覚のような応答：

要求：

OPTIONS /conversion HTTP/1.1 

応答：RFC 2616で定義されて

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

Answer 1

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

Answer 2

タイトルへの回答：「HTTP OPTIONS要求に応答する方法」それに答えるために、私はあなたがOPTIONSリクエストに応えたい理由を知りたいのですが？誰があなたにOPTIONSリクエストを送信していますか、なぜですか？ Many public servers respond with some form of "error" or "not allowed"（500,501,405）。したがって、クライアントがOPTIONSリクエストを合理的に送信し、有用で有意義な情報（WebDAV、CORSなど）を返すような特定の状況にない場合は、おそらく「それはしないでください」と返答したいと考えています。

"OPTIONS/conversion HTTP/1.1"リクエストに関するご質問：あなたのサーバーのクライアントがあることが分かっていない場合は、OPTIONS要求を "/ conversion"に送信し、 「許可する：コンバート」と答えた場合、そのような回答は理にかなっていません。私は、ほとんどの実装がを実行すると、はOPTIONSをサポートし、 "許可"で応答すると、標準のHTTPメソッドで応答すると思います。

Here's a great article on the topic。

要約：OPTIONSはキャッシュをサポートしていないため、すぐに問題があります。代替方法：サーバー全体のメタデータ：well-known URI'sを試してください。リソース固有：レスポンスにLink headerを使用するか、そのリソースの表現形式のリンクを使用してみてください。

最後に、お手数ですがWADLまたはRSDLをご覧ください。

EDIT：

dotnetguyは以下のコメントで良い点を作る：オプションは、特定のコンテキスト（例えば、CORS）に紛れもなく貴重です。私は確かに他に示唆することを意味しませんでした。