I was going to write a quick note about how to suppress Expect 100-Continue as a result of this forum post. But it seems no one’s covered the background of WCF best practices for manipulating HTTP headers in general. So first, this post 🙂

Back in Beta 2, we stepped up our first class HTTP support by allowing WCF users to access and manipulate the HTTP headers that are sent on the wire. The programming model interface to this feature is through two Message Properties: HttpRequestMessageProperty (for HTTP requests) and HttpResponseMessageProperty (for HTTP responses, as you might expect). They are represented as Message Properties and not Message Headers since they are transport-specific information that is stored “outside” of the Message. Message Headers require an infoset-based representation that is included in serialization over all transports.

Using the HTTP-based Message Properties is very straightforward. First, you setup the contents of your Property. Then you attach it to your outgoing OperationContext or to your outgoing Message (if you are using the Message programming model directly). For example, if I wanted to send a GET request through WCF, I would do the following:

For incoming requests/responses, you can look up the HTTP-specific information by looking for the Property on your incoming context:

HttpRequestMessageProperty httpRequestProperty = null;
object propertyValue = null;

if (OperationContext.Current.IncomingMessageProperties.TryGetValue(HttpRequestMessageProperty.Name, out propertyValue))
{
  httpRequestProperty = (HttpRequestMessageProperty)propertyValue;
}

If this property is non-null (note that you could be accessing a Message that came in over a non-HTTP transport), then it will faithfully represent the information associated with the HTTP-specific data that was associated with this request. The above approach also applies to HTTP responses. The difference is that you use the HttpResponseMessageProperty class, and the non-header items that you can manipulate include Status Code and Status Description (rather than Verb and Query String on the request).