405 (POST not allowed) HttpException when trying to apply HttpResponse.Filter - .net-4.0

Question

We are getting a 405 error and the following exception from IIS7 when attempting to apply a ResponseStreamFilter to HttpResponse.Filter:
HttpException:
The HTTP verb POST used to access path '/app/Thing.asmx/Command' is not allowed.
We are applying the filter by using an HttpModule with code like this:
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.");
All of the code in our HttpModule works just fine... it's all wrapped in a try-catch just to be safe and isn't throwing any exceptions, and diagnostic logging like the last line above is working correctly.
But it looks like our ProcessStream method in the above code is never being called. If we apply the filter to HttpResponse.Filter at all, IIS throws the 405 exception before our filter begins processing.
Our code has worked before on several similar systems, so we suspect IIS/machine configuration on this specific server is responsible. What could be causing this?
The most commonly reported cause for a 405 error in a situation like this seems to be using Url.Rewrite. (The HTTP verb POST used to access path '/test.html' is not allowed) However, we are never using a Url.Rewrite.
Another commonly reported cause is trailing slashes in the request URL. (HTTP 405 on Error on HTTP POST IIS ASP .NET) But as mentioned above, the URL being requested does not end with a slash.
The app pool is running .NET 4.0 in a Classic pipeline (jQuery AJAX post receives 405 error (HTTP verb POST not allowed)), but our code has run without issue on many other systems under a Classic app pool, so there would still have to be something unique to this server's configuration. Changing to Integrated pipeline breaks the application our code is filtering, so that's not a possible workaround anyway.

Answer 1

Turns out, it was a very obscure IIS bug:
http://support.microsoft.com/kb/980368
The ExtensionlessUrl handler (*.) was incorrectly getting involved with the request instead of just the WebServiceHandlerFactory (*.asmx) as expected. The workaround was:
Manually deleting the ExtensionlessUrl handler entries from the web application's handler mappings
Manually moving the ExtensionlessUrl handler entries under anything you actually expect to be hit
Adding a web.config entry under system.webServer/handlers to remove the ExtensionslessUrl handler as needed (we went with this option to make sure it got included with app demployment)
We had to burn a Microsoft support ticket on this one, since there's no way we would have figured this out in any reasonable timeframe. Hopefully this helps someone else.