I've got a service setup using the CorsFeature, and am using the approach that mythz suggested in other answers, collected in a function used in the appHost file:
private void ConfigureCors(Funq.Container container)
{
Plugins.Add(new CorsFeature(allowedOrigins: "*",
allowedMethods: "GET, POST, PUT, DELETE, OPTIONS",
allowedHeaders: "Content-Type, Authorization, Accept",
allowCredentials: true));
PreRequestFilters.Add((httpReq, httpRes) =>
{
//Handles Request and closes Responses after emitting global HTTP Headers
if (httpReq.HttpMethod == "OPTIONS")
{
httpRes.EndRequest();
}
});
}
However, the pre-request filter is only firing on some of the service requests. One of the base entities we have in the service is a question entity, and there are custom routes defined as follows:
[Route("/question")]
[Route("/question/{ReviewQuestionId}", "GET,DELETE")]
[Route("/question/{ReviewQuestionId}/{ReviewSectionId}", "GET")]
Using POSTMAN to fire test queries (all using the OPTIONS verb), we can see that this will fire the pre-request filter:
http://localhost/myservice/api/question/
But this will not:
http://localhost/myservice/api/question/66
Presumably, this is because the second and third routes explicitly defined the verbs they accept, and OPTIONS isn't one of them.
Is it really necessary to spell out OPTIONS in every defined route that restricts the verbs supported?
