Labor Day 2009 and an HTTP Question

Today is a US national holiday, which generally means I don’t put up a post due to the drastically reduced number of readers. Here’s a look ahead at some of the topics coming this week though:

- Final part of the series on named pipes

My notes on HTTP listener error codes  

• A look at the WCF binary encoding protocol

And, for those of you not in the US or Canada, here’s a short post to tide you over today.

Is it possible for an HTTP channel to fault?

The HTTP transport channel functions as a datagram channel. That means it effectively is a singleton implementation that should almost never fail. There are a few things that could go wrong to make an HTTP channel fault, but you still might not necessarily do anything about that. For example, a faulting HTTP channel could be caused by a bug in your code or a bug in our code (typically manifested as an InvalidOperationException). It’s probably best for your program to die so that the bug can be found and fixed.

There are also a few edge cases where even a singleton HTTP channel can run into permanently fatal trouble. There are universally fatal conditions, such as running out of memory or the app domain blowing up, but there are also a few fatal incidents unique to HTTP. One example on the client side is that the channel might fail to open when authentication is being used because the source of security tokens was unresponsive. An example on the server side is that the underlying HTTP listening service might have fallen down (in IIS hosting this probably would have killed the process before getting to us because the application process and HTTP listener are part of the same system but in self hosting the two are separate and can live independently).