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?
The PreRequestFilters is only fired for valid routes which doesn't exclude OPTIONS (e.g. by leaving Verbs=null
and allow it to handle all Verbs instead - inc. OPTIONS).
To be able to handle all OPTIONS requests (i.e. even for non-matching routes) you would need to handle the Request at the start of the Request pipeline (i.e. before Routes are matched) with Config.RawHttpHandlers
. This is done in the CorsFeature for you in the next major (v4) release of ServiceStack with:
//Handles Request and closes Response after emitting global HTTP Headers
var emitGlobalHeadersHandler = new CustomActionHandler(
(httpReq, httpRes) => httpRes.EndRequest());
appHost.RawHttpHandlers.Add(httpReq =>
httpReq.HttpMethod == HttpMethods.Options
? emitGlobalHeadersHandler
: null);
CustomActionHandler doesn't exist in v3, but it's easily created with:
public class CustomActionHandler : IServiceStackHttpHandler, IHttpHandler
{
public Action<IHttpRequest, IHttpResponse> Action { get; set; }
public CustomActionHandler(Action<IHttpRequest, IHttpResponse> action)
{
if (action == null)
throw new Exception("Action was not supplied to ActionHandler");
Action = action;
}
public void ProcessRequest(IHttpRequest httpReq, IHttpResponse httpRes, string operationName)
{
Action(httpReq, httpRes);
}
public void ProcessRequest(HttpContext context)
{
ProcessRequest(context.Request.ToRequest(GetType().Name),
context.Response.ToResponse(),
GetType().Name);
}
public bool IsReusable
{
get { return false; }
}
}
Another way to match all Routes is to specify a FallbackRoute, e.g to handle all routes you can add a wildcard to the Fallback route with:
[FallbackRoute("/{Path*}")]
public class Fallback
{
public string Path { get; set; }
}
But as it matches all un-handled routes it no longer gives 404 for non-matching requests since all un-matched routes are now matched. But you can easily handle it manually with:
public class FallbackService : Service
{
public object Any(Fallback request)
{
if (base.Request.HttpMethod == "OPTIONS")
return null;
throw HttpError.NotFound("{0} was not found".Fmt(request.Path));
}
}
You don't have to add the OPTIONS
verb to all routes. Instead you can do the following:
Just put this route on your Question
class:
[Route("/question/{*}", Verbs = "OPTIONS")]
public class Question
{
}
Then add this to your question services class:
public void Options(Question question)
{
}
Now any route starting with /question/
will support the OPTIONS
verb.
You might want to restrict this if you're going to have subroutes like /question/something/
though.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With