IIS 8.5上的HTTP PUT失败

Question

This seems to be getting deeper into IIS than I'm good at! So I have a Web API controller that is working great for GET and POST. The first screenshot shows a handling of a GET. Everything was great I get a response.

View Full Size

But then I make a PUT request and it all falls apart. It seems to cruise through the ManagedPipelineHandler and then falls through to the DefaultDocumentModule and fails with a 405.

View Full Size

View Full Size

There is no WebDAV installed and I've tried to remove it anyway at the web.config level. Handlers are overridden to support PUT.

<handlers>
  <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
  <remove name="OPTIONSVerbHandler" />
  <remove name="TRACEVerbHandler" />
  <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" />
</handlers>

Despite this the request is failing to be handled by ASP.NET and I'm looking for some ideas on debugging? Here is the action method that fails, the PUT and one that works, a GET.

public class ProductsController : ApiController
{
    [HttpPut]
    [Route("api/products")]
    public AddProductResponse AddProduct(AddProductRequest request)
    {
        return new AddProductResponse(); 
    }

    [HttpGet]
    [Route("api/products/manufacturers")]
    public ManufacturersResponse GetProductManufacturers()
    {
        var productService = new ProductService();
        var manufacturers = productService.GetManufacturers();
        return new ManufacturersResponse { Manufacturers = manufacturers.OrderBy(m => m.BusinessName) };
    }
}

Seems I missed the hand off early in the request lifecycle.

FREB seems to show the GENERAL_SHILD_REQUEST_START for the PUT, not sure why the managed pipeline is creating that extra child request that ultimately falls to the DefaultDocumentModule which can't handle a PUT.

Answer 1

Looked at your scenario (thanks for sharing you repro project), and the issue is that the projected placed the webapi in a /api folder inside the project.

Specifically there was also /api/products, so when the path /api/products was hit for the http put, IIS seen it as a directory browsing request, and refused to serve a PUT verb on it.

Solution: Rename the api folder, and in general try not to map folders right where REST APIs are being called. This wouldn't have been an issue in deployment but on the local Web Application the folder is there and IIS gets to handle it first.

Another solution (though less recommended) is to use

<modules runAllManagedModulesForAllRequests="true" />

That will let ASP.NET get a first crack ahead of IIS, this is however not a recommended practice just to solve a small problem like this.

Answer 2

I had a similar problem. My PHP REST Api was returning 404 for the verbs PUT and DELETE in IIS 8.5. Turns out that the Fast CGI Module wasn't receiving all verbs by default.

To fix it, I added this to web.config:

<system.webServer>
    <handlers>
        <remove name="PHP55_via_FastCGI" />
        <add name="PHP55_via_FastCGI" path="*.php" verb="*" modules="FastCgiModule" scriptProcessor="C:\Program Files (x86)\PHP\v5.5\php-cgi.exe" resourceType="Either" requireAccess="Script" />
    </handlers>
    ...

This is for PHP, but I hope this helps someone.