405 (POST не разрешен) HttpException при попытке применить HttpResponse.Filter

Question

Мы получаем ошибку 405 и следующее исключение из IIS7 при попытке применить ResponseStreamFilter к HttpResponse.Filter:

HttpException: 
The HTTP verb POST used to access path '/app/Thing.asmx/Command' is not allowed.

Мы применяем фильтр, используя HttpModule с кодом, подобным этому:

var rfs = new ResponseFilterStream(HttpContext.Current.Response.Filter);
rfs.TransformStream +=
    new Func<System.IO.MemoryStream, System.IO.MemoryStream>(ProcessStream);
HttpContext.Current.Response.Filter = rfs;
Log("Response stream filter applied correctly.");

Весь код в нашем HttpModule работает просто отлично... он полностью упакован в try-catch просто для безопасности и не выдает никаких исключений, а диагностика, как и в последней строке выше, работает правильно.

Но похоже, что наш ProcessStream метод в приведенном выше коде никогда не вызывается. Если мы применим фильтр к HttpResponse.Filter вообще IIS выдает исключение 405 до того, как наш фильтр начнет обработку.

Наш код ранее работал на нескольких похожих системах, поэтому мы подозреваем, что ответственность за настройку IIS/ машины на этом конкретном сервере. Что может быть причиной этого?

Наиболее распространенная причина ошибки 405 в подобной ситуации - использование Url.Rewrite. ( Глагол HTTP POST, используемый для доступа к пути "/test.html", недопустим). Однако мы никогда не используем Url.Rewrite.

Другая причина, о которой обычно сообщают, - это косые черты в URL-адресе запроса. ( HTTP 405 при ошибке в HTTP POST IIS ASP.NET) Но, как упоминалось выше, запрашиваемый URL-адрес не заканчивается косой чертой.

Пул приложений работает на.NET 4.0 в классическом конвейере ( пост JQuery AJAX получает ошибку 405 (HTTP-глагол POST не разрешен)), но наш код без проблем работает на многих других системах в пуле классических приложений, поэтому все равно быть чем-то уникальным для конфигурации этого сервера. Переход на интегрированный конвейер нарушает работу приложения, который фильтрует наш код, так что в любом случае это не обходной путь.

Answer 1

Оказывается, это была очень неясная ошибка IIS:

http://support.microsoft.com/kb/980368

Обработчик ExtensionlessUrl (*.) неправильно связывался с запросом, а не только с WebServiceHandlerFactory (*.asmx) как и ожидалось. Обходной путь был:

1. Удаление записей обработчика ExtensionlessUrl вручную из отображений обработчиков веб-приложения
2. Перемещение записей обработчика ExtensionlessUrl вручную под все, что вы ожидаете получить
3. Добавление записи web.config в system.webServer/handlers для удаления обработчика ExtensionslessUrl по мере необходимости (мы пошли с этой опцией, чтобы убедиться, что она включена в demployment приложения)

Мы должны были сжечь билет поддержки Microsoft на этом, так как мы никак не могли бы выяснить это в любой разумный период времени. Надеюсь, это поможет кому-то еще.