PUT and DELETE requests to a MVC 4 Web Api application we released to a customer server were failing with a 405 status code - Method Not Allowed.
After some investigation on the web, the WebDAV module was the cause - this thread on the IIS forum has a good overview of why it occurs (PUT and DELETE are considered WebDAV verbs) and how to uninstall the feature.
Exception shielding (or exception sanitation) is a integration pattern that should always be implemented to ensure unexpected exceptions never arrive at the client (a.k.a bleed through).
For MVC 4's Web Api - this is achieved by overriding the OnException method, on the ExceptionFilterAttribute class. Here you can inspect the exception that was thrown, and sanitise if required (change the exception to be more generic).
However, the mechanism to return http status codes - e.g. 404 - when a resource is not found, is to throw an HttpResponsException with the appropriate status code. This ensures that RESTful semantics are upheld.
During development, I updated the OnException method to ignore exceptions of type HttpResponsException, as these are intended to reach the client. However the method was never invoked. After some googling, I discovered the filter is smart enough to know that HttpResponseExceptions should be ignored - "An exception filter is executed when a controller method throws any unhandled exception that is not an HttpResponseException exception. TheHttpResponseException type is a special case, because it is designed specifically for returning an HTTP response."
Similar problem to my post around IDependencyResolver,
Custom action filters for web api controllers need to be derived from System.Web.Http.Filters.ActionFilterAttribute
.... rather than System.Web.Mvc.ActionFilterAttribute
I've started playing around with the new ASP.Net Web Api (available as part of MVC 4), and was completely stumped as to why the GetService method on IDependencyResolver was not being called when my API controller was being requested.
Controllers that were derived from Controller, GetService was called, however any controller deriving from ApiController GetService was not being fired (resulting in the No parameterless constructor defined for this object exception being thrown).
Little did I know, IDependencyResolver for ApiControllers is a completely different type and is 'set' on a different resolver.
Web API: System.Web.Http.Services.IDependencyResolver
Http: System.Web.Mvc.IDependencyResolverAnd for setting the resolver for ApiControllers, it should be done as GlobalConfiguration.Configuration.ServiceResolver.SetResolver()
Rather than DependencyResolver.SetResolver()