“405 method not allowed” in IIS7.5 for “PUT” method

Question

I use WebClient type to upload *.cab files to my server. On the server side, I registered a HTTP handler for *.cab file with the PUT method as below:

Answer 1

Best to just remove the unused WebDAV feature. Go to Programs and Features => Turn Windows Features On or Off and disable WebDAV Publishing under

Internet Information Services => World Wide Web Services => Common HTTP Features

Answer 2

I had the same problem, with a RESTful API running on aspnet core.

I didn't want to uninstall the WebDAV, and I tried most of the remedies described above. I tried to set the verbs="*" both on the site and on the server itself, but without success.

What did the trick for me was the following:

IIS Manager -> Sites -> MySite -> HandlerMappings -> aspNetCore -> Edit

-> Request Restrictions -> Access -> None (it was Script).

After that everything worked, even if I replaced the original WebDAV options.

Answer 3

Here is what worked for me:

Open up IIS and click on your Site.

1 - Double Click on the Modules 2 - Right Click on WebDavPublishing and remove. 3 - Restart running WebSite.

Answer 4

Another tip from me. I have used PHP + IIS, and the Handler Mappings for PHP did not have the PUT verb.

Go to IIS Manager->Your site->Handler Mappings->PHPxx_via_FastCGI->Request Restrictions->Verbs, then add PUT.

That's it!

Answer 5

Often this error is caused by the WebDAV module that try to handle this kind of requests. An easy solution is to remove it from modules and from handlers of the system.webServer section just inside your web.config file. Here a configuration example:

<system.webServer>
    <modules>
        <remove name="WebDAVModule" />
    </modules>
    <handlers>
        <remove name="WebDAV" />
    </handlers>
</system.webServer>

Answer 6

In my case I had relocated Web Deploy to another port, which was also the IIS port (not 80). I didn't realize at first, but even though there were no errors running both under the same port, seems Web Deploy was most likely responding first instead of IIS for some reason, causing this error. I just moved my IIS binding to another port and all is well. ;)