IIS 7.5, Web Service and HTTP 405 error

Question

I have a web service which I host on my machine. I use Windows 7 and IIS 7.5.

Problem: When the client tries to consume the web service, he/she ge

Answer 1

For people who bump into this page but are making requests to a web application with aspx pages, instead of services, there's one important thing to note.

If you make a fiddler http post request to http://localhost/MyApplication, it will throw status 405. But if you specify http://localhost/MyApplication/Default.aspx instead, it will respond correctly (with status 200)

Hope this helps. I've been looking in the wrong place for an hour, debugging handlers, modules, webdav settings, http verbs, etc.

Answer 2

Goto IIS Manager -> Select Web Site -> Handler Mapping -> Select the handler -> right-click and select edit -> Request restrictions -> verbs tab

Change the value there.

Depending on your extension, it could be a different handler.

Answer 3

The listed answer didn't work for me, but I was able to fix the problem by running

"%WINDIR%\Microsoft.Net\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe" -r

This re-registered the handler mapping for *.svc

Answer 4

Turns out I didn't have WCF HTTP-Activation enabled. Solution here: WCF on IIS8; *.svc handler mapping doesn't work

Answer 5

After hours of struggling, this is final solution that helped me (tested from fiddler):

1. On IIS 7.5 -> YourWebsite -> Handler Mappings
2. Choose "Add module mapping" option on the right side of the panel
3. In "Request path" field enter *.wsdl
4. In "Module" field enter "ProtocolSupportModule"
5. Click on "Request restrictions" and go to Verbs tab
6. Enter POST verb
7. Save changes

End voila, fiddler no longer answers with 405 but with happy 200.

Answer 6

Ahh -- I've finally found a solution to my CORS on IIS hell. This was one of the problems that popped up during my solution finding.

The correct answer is aliostad's -- The problem comes from the fact that for some solutions for implementing the 'OPTIONS' verb, removal of the mapping of that verb to the ProtocolSupportModule was recommended. Or perhaps someone just cleaned out the unnecessary mappings, etc. This left no handler for OPTIONS.

I'm not an expert on exactly what happens behind the scenes, but it seems that IIS makes sure there is a potential handler for the request long before the Application_BeginRequest event is fired, this despite their sequence diagrams:

https://msdn.microsoft.com/en-us/library/bb470252.aspx

So a 405 status is returned without ever executing your module. What was being sent to the server is for example:

OPTIONS http://www.example.com/path/mypage.aspx

So IIS is looking for a handler for *.aspx that accepts the OPTIONS verb. If you look at your default applicationHost.config file, you'll see, for example:

        <add name="PageHandlerFactory-ISAPI-4.0_32bit" path="*.aspx" verb="GET,HEAD,POST,DEBUG" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
        <add name="PageHandlerFactory-ISAPI-4.0_64bit" path="*.aspx" verb="GET,HEAD,POST,DEBUG" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
        <add name="PageHandlerFactory-Integrated-4.0" path="*.aspx" verb="GET,HEAD,POST,DEBUG" type="System.Web.UI.PageHandlerFactory" preCondition="integratedMode,runtimeVersionv4.0" />
        <add name="PageHandlerFactory-Integrated" path="*.aspx" verb="GET,HEAD,POST,DEBUG" type="System.Web.UI.PageHandlerFactory" preCondition="integratedMode" />

I had just done the following in my web.config to make IIS stop returning status 200 noops:

        <remove name="OPTIONSVerbHandler" />

So, trying it at first, and concluding that this is what was needed, I added the following to my web.config:

        <remove name="PageHandlerFactory-ISAPI-4.0_32bit" />
        <remove name="PageHandlerFactory-ISAPI-4.0_64bit" />
        <remove name="PageHandlerFactory-Integrated" />
        <remove name="PageHandlerFactory-Integrated-4.0" />

        <add name="PageHandlerFactory-ISAPI-4.0_32bit" path="*.aspx" verb="GET,HEAD,POST,DEBUG,OPTIONS" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
        <add name="PageHandlerFactory-ISAPI-4.0_64bit" path="*.aspx" verb="GET,HEAD,POST,DEBUG,OPTIONS" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
        <add name="PageHandlerFactory-Integrated-4.0" path="*.aspx" verb="GET,HEAD,POST,DEBUG,OPTIONS" type="System.Web.UI.PageHandlerFactory" preCondition="integratedMode,runtimeVersionv4.0" />
        <add name="PageHandlerFactory-Integrated" path="*.aspx" verb="GET,HEAD,POST,DEBUG,OPTIONS" type="System.Web.UI.PageHandlerFactory" preCondition="integratedMode" />

Note that the replacements match what is in applicationHost.config, except with the extra OPTIONS verb added to each line.

For those of you who are using routing (MVC or webapi for example):

        <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
        <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
        <remove name="ExtensionlessUrlHandler-Integrated-4.0" />

        <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="C:\windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
        <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="C:\windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
        <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />

Lastly, I'm no IIS expert -- perhaps there is a different more efficient way to handle the OPTIONS verb for CORS (more specifically, allow your CORS handler to work without the 'custom header' partial solution, I'm open to those solutions.