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 работает просто отлично ... все это обернуто в примерки улове только быть безопасным и не кидает каких-либо исключений, и диагностическая регистрация как последняя строка abov e работает правильно.

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

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

Наиболее часто сообщаемая причина ошибки 405 в подобной ситуации, похоже, использует Url.Rewrite. (The HTTP verb POST used to access path '/test.html' is not allowed) Однако мы никогда не используем Url.Rewrite.

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

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

Answer 1

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

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

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

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

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