How to configure IIS 7.5 to allow Inserts and Deletes with WCF Data Services (PUT and DELETE)

Question

I have a WCF Data Service that works fine on my development system. But when I deployed it to my client's web server, inserts, updates, and deletes all failed. Updates failed with "401 - Unauthorized: Access is denied due to invalid credentials." This seems to be an integrated authentication problem. I found a workaround on StackOverflow involving setting full permissions on my .svc file for "Authenticated Users" and now updates work. I also found a WCF Data Services blog that explains the right way to fix this problem, which I will implement later.

But inserts and deletes still don't work. I'm getting "405 - HTTP verb used to access this page is not allowed."  As verified with Fiddler, the verbs are PUT and DELETE.

In IIS Manager, the service is deployed as an application under the website. Its Application Pool is "ASP.NET v4.0," and Pipeline Mode is Integrated.

The following is what I know about mapping verbs. I right-click on the application and then click Handler Mappings, and I find "svc-Integrated-4.0" registered for the path *.svc. When I click Edit for that, then Request Restrictions, then Verbs, "All Verbs" is selected.

I'm stuck – how can I get this to work?

Answer 1

If you are using one of the WCF Data Services clients, you can set DataServiceContext.UsePostTunneling to true. This tells the client to send all CUD requests as POST requests to the service, which should solve your immediate problem as it sounds like POST requests are accepted. From the documentation:

POST Tunneling

By default, the client library sends create, read, update, and delete requests to an OData service by using the corresponding HTTP methods of POST, GET, PUT/MERGE/PATCH, and DELETE. This upholds the basic principles of Representational State Transfer (REST). However, not every Web server implementation supports the full set of HTTP methods. In some cases, the supported methods might be restricted to just GET and POST. This can happen when an intermediary, like a firewall, blocks requests with certain methods. Because the GET and POST methods are most often supported, OData prescribes a way to execute any unsupported HTTP methods by using a POST request. Known as method tunneling or POST tunneling, this enables a client to send a POST request with the actual method specified in the custom X-HTTP-Method header. To enable POST tunneling for requests, set the UsePostTunneling property on the DataServiceContext instance to true.

 

Cheers,

Glenn Gailey

---

Please visit my blog

This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 2

Thank you Glenn, that seems to have fixed the problem.

--Howard

Answer 3

Now that I have this workaround, my  incentive to investigate the original problem is very low.

However, you might be interested that (1) the problem occurs when I run a test client locally on the server, so this isn't a firewall problem and (2) I saw the same behavior when I deployed your Code First Northwind ODATA service.

I wonder if I'm the only person who ran into this?

In any case, thanks for the prompt help – I think ODATA is going to be great for the application I'm building.

Answer 4

I have seen other people hit this, and it seems to be more common on IIS running on Azure. However, this is not strictly an OData issue, per-se, but rather a challenge with many web server implementations. This is why the OData protocol provides for post tunneling, to support cases where the web server cannot be made to support REST methods other than GET and POST (usually by policy). It personally drives me crazy to try and track down these IIS issues, which is why I generally just use the post tunneling support in our client.

---

Please visit my blog

This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 5

In my case POST tunneling was not an option since I am hosting a public API that has been around for quite some time now.

Luckily I found another fix for the problem: Simply enable forms authentication for the site in ISS Manager (strangely enough this does not seem to be part of the regular web.config?), and PUT / DELETE will be working fine again.

---

Adrian Grigore http://www.logmytime.de