You created a WCF Data Services service, and client applications receive errors when they submit PUT or DELETE requests. You need to support these operations, even when intermediaries do not allow those HTTP verbs directly. Which header and request type combination should the client use?

Introduction / Context:
WCF Data Services uses HTTP verbs such as GET, POST, PUT, and DELETE to implement CRUD operations on data exposed through an OData service. However, some firewalls, proxies, or hosting environments restrict PUT and DELETE requests. To work around this limitation, WCF Data Services supports tunneling these verbs through POST requests by using a special header. Understanding how to configure the client request to use method tunneling is an important part of working with HTTP based services in constrained environments.

Given Data / Assumptions:

You created a WCF Data Services service targeting .NET Framework 4.

Client applications attempt to send PUT or DELETE requests but encounter errors due to intermediaries blocking these verbs.

You want to maintain semantic PUT and DELETE operations without reconfiguring network infrastructure.

WCF Data Services supports a method override mechanism using HTTP headers.

You must choose the correct header and base request type so that the service receives the intended operation.

Concept / Approach:
WCF Data Services supports the X-HTTP-Method header, which allows a client to send a POST request that is logically interpreted as a PUT or DELETE operation by the service. The client sets the X-HTTP-Method header to PUT or DELETE and uses POST as the actual HTTP method. Intermediaries see only POST requests, which are usually allowed, while the service reads the header and executes the correct operation. Using ContentType headers or method overrides on GET requests does not provide the required semantics for updating or deleting resources.

Step-by-Step Solution:
1. On the client side, create an HTTP request targeting the WCF Data Services resource that you want to update or delete. 2. Set the HTTP method of the request to POST so that it passes through intermediaries that do not allow PUT or DELETE. 3. Add the X-HTTP-Method header to the request and set its value to PUT for updates or DELETE for deletions. 4. Include any required payload or headers (such as Content-Type) appropriate for the operation and resource type. 5. When the service receives the POST request, it inspects the X-HTTP-Method header and maps the request to the corresponding PUT or DELETE operation internally.

Verification / Alternative check:
You can test this behavior by sending both a direct PUT request and a POST request with X-HTTP-Method set to PUT and confirming that the service handles both in the same way. Network traces will show POST traffic on the wire, while service logs indicate that update or delete operations are executed. Official WCF Data Services documentation describes this header based method tunneling as a compatibility feature.

Why Other Options Are Wrong:
Sending X-HTTP-Method with a GET request does not make sense, because GET is defined as a safe and idempotent method used only for retrieval, not modification or deletion of resources.
Using only the ContentType header, whether with POST or GET, controls the format of the request body but does not change the semantics of the HTTP method and therefore cannot be used to tunnel PUT or DELETE in this scenario.

Common Pitfalls:
A common mistake is to assume that setting ContentType or custom query parameters is enough to indicate an update operation, which violates REST principles and does not work with WCF Data Services. Another pitfall is forgetting to use POST as the actual method when intermediaries block PUT or DELETE. Always use POST together with X-HTTP-Method for method tunneling in restrictive environments.

Final Answer:
The client should send a POST request with an X-HTTP-Method header indicating PUT or DELETE so that WCF Data Services can perform the correct operation.