10

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 gets a HTTP 405 error.

In the log file of IIS, I can see that this is refused because POST verb is not allowed.

Question: How can I allow POST verb for those requests?
Do I have to add mapping of the WSDL file? And if I do, how do I have to configure this mapping? I have checked, and in existing mappings I have nothing for WSDL extension.

Is there maybe another thing to setup on IIS to allow those requests?

Web service is built using WCF.

mhu
  • 17,099
  • 10
  • 54
  • 83
buhtla
  • 2,489
  • 4
  • 21
  • 36
  • Make sure you install .NET 4.0 on the computer. Make sure you see this: http://support.microsoft.com/kb/2015129 –  Jun 22 '13 at 10:52

6 Answers6

14

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.

buhtla
  • 2,489
  • 4
  • 21
  • 36
  • Buhtla, if this is the answer that solved the problem for you, mark it as such with the green checkmark. This is allowed (and encouraged) on SO. – Peter Apr 24 '12 at 13:36
  • How did you find out about this @buhtla? It worked for me: big thanks! But I think it would also be helpful to post the URL from where you got this information and, please, mark as answer because it will be easier for others to find the solution. – Fabio Milheiro Jul 12 '12 at 11:42
  • I'm very glad I helped you guys! It passed quite some time after I had this problem, but I remember I found out this solution on my own. Maybe there are some pages that have this same resolution of the problem described, but I'm not aware of them. – buhtla Oct 01 '12 at 08:48
  • Worked for me as well, you are great! – UMAR-MOBITSOLUTIONS Feb 24 '14 at 17:31
7

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

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.

Aliostad
  • 76,981
  • 19
  • 152
  • 203
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.

Daniel Hursan
  • 839
  • 1
  • 8
  • 19
0

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

Community
  • 1
  • 1
northben
  • 4,682
  • 3
  • 31
  • 45
0

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.

Gerard ONeill
  • 3,193
  • 31
  • 22