HTTP PUT Ошибка в IIS 8.5

Question

Это, кажется, все глубже проникает в IIS, чем я хорош! Поэтому у меня есть контроллер веб-API, который отлично работает для GET и POST. На первом снимке экрана отображается обработка GET. Все было замечательно, я получаю ответ.

View Full Size

Но тогда я сделать запрос PUT и все разваливается. Это, кажется, круиз через ManagedPipelineHandler и затем проваливается к DefaultDocumentModule и не с 405.

View Full Size

View Full Size

Там нет WebDAV установлен и я попытался удалить это в любом случае на уровне web.config. Обработчики переопределяются для поддержки 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> 

Несмотря на это, запрос не обрабатывается ASP.NET, и я ищу некоторые идеи по отладке? Вот метод действия, который терпит неудачу, PUT и один, который работает, 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) }; 
    } 
} 

Кажется, я пропустил руку в начале жизненного цикла запроса.

FREB, кажется, показывает GENERAL_SHILD_REQUEST_START для PUT, не уверен, почему управляемый конвейер создает дополнительный дочерний запрос, который в конечном итоге попадает в модуль DefaultDocumentModule, который не может обрабатывать PUT.

Answer 1

Посмотрел на ваш сценарий (спасибо за совместное использование репрограммного проекта), и проблема заключается в том, что проецируемый помещал webapi в папку/api внутри проекта.

В частности, было также/api/products, поэтому, когда путь/api/products был поражен для http put, IIS рассматривал его как запрос на просмотр каталога и отказался обслуживать глагол PUT на нем.

Решение: Переименуйте папку api и вообще не пытайтесь сопоставлять папки прямо там, где вызывается API REST. Это не было бы проблемой при развертывании, но в локальном веб-приложении была папка, и IIS сначала обрабатывает ее.

Другое решение (хотя и менее рекомендуется) использовать

<modules runAllManagedModulesForAllRequests="true" /> 

Это позволит ASP.NET получить первую трещину впереди IIS, это, однако, не рекомендуется просто решить небольшую проблему, как это ,

Answer 2

У меня была аналогичная проблема. Мой PHP REST Api возвращал 404 для глаголов PUT и DELETE в IIS 8.5. Оказывается, что Fast CGI Module не получал все глаголы по умолчанию.

Чтобы исправить это, я добавил это 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> 
    ... 

Это для PHP, но я надеюсь, что это поможет кому-то.