Modifying HTTP Error Codes, Part 1

Back to errors and faults for a bit with this two part series on modifying the HTTP status code used for fault messages. First, we'll need some background.

What happens at the HTTP level when a web service encounters a problem? That's a good question because it's not clear at all from programming the service what's going to happen under the covers. Let's build a service and find out. Here's the simplest web service I could think of that has a slight problem. I'll be hosting this in IIS so there's no other code needed to get going. You can imagine the configuration that goes along with this service, but I'm going to omit any discussion of that because it won't be relevant to anything we have to look at.

 [ServiceContract]
public interface IService
{
   [OperationContract(Action = "*", ReplyAction = "*")]
   Message Action(Message m);
}

public class Service : IService
{
   public Message Action(Message m)
   {
      throw new FaultException("!");
   }
}

We can cut all the crud out of the messages by using a POX binding: a text encoder with MessageVersion set to None and a normal HTTP transport. Now, we can run this service and see what happens. I'm just going to telnet to the service address so that we can easily see all of the HTTP headers.

 HTTP/1.1 500 Internal Server Error
Content-Type: application/xml; charset=utf-8
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Tue, 10 Jan 2007 06:25:16 GMT
Connection: close
Content-Length: 159

<Fault xmlns="https://schemas.microsoft.com/ws/2005/05/envelope/none"><Code><Value>Sender</Value></Code><Reason><Text xml:lang="en-US">!</Text></Reason></Fault>

This shows us that our service fault exception results in an HTTP status code of 500 for the response. The body of the message is something that looks a lot like a SOAP fault, but smaller because we said we weren't going to use SOAP. Inside the fault message you can see the fault elements that we talked about in past articles, and it's clear that we can modify anything inside the fault. It's not clear though what we modify to alter the framing of the HTTP response. That brings us to the actual question for this pair of articles.

How do I modify the HTTP status code that gets sent back with a fault?

We'll answer that question next time, which is going to require writing a bit more code.

Next time: Modifying HTTP Error Codes, Part 2

Comments

• Anonymous
  January 23, 2007
  I've enabled tracing in my application, but I don't see entries in the trace log show up until I restart

• Anonymous
  February 19, 2007
  I haven't forgotten about the goal to put together a table of contents for all of these articles. The