The way you extend a lot of WCF is through custom behaviors. This case is no different. We can use a custom behavior to inject an additional channel dispatcher into our service on startup. A channel dispatcher allows us to intercept messages that match a specific filter and forward the message to an implementation class for handling. By injecting a custom channel dispatcher, we can layer additional contracts on top of our WCF service to accept messages that aren’t defined by the service contract that is configured for the service host. In this case, we want to intercept raw HTTP GET requests (since SOAP requests will be POST requests) and return an HTML page instead of forwarding the message to the hosted service.

In theory, this should be pretty straightforward, but a few flaws in the design of WCF make this a bit harder than it should be:

1. A channel dispatcher requires a channel listener in order to accept messages. A channel listener can be constructed from a binding, but unfortunately, the http transport part of the binding doesn’t let you set up a listener for GET requests and a listener for POST requests at the same URL. It’s possible to configure this, and that is how the built in behavior works, but unfortunately, the WCF team decided to make the required property internal. The only way to get the appropriate behavior is via reflection. It’s not pretty, but it works.
2. A channel dispatcher also requires an instance context provider. The instance context provider determines the instancing behavior of a class that receives dispatched messages. WCF ships with multiple instance context modes in the box. Unforunately, all the providers and factories for those providers are also internal. You could theoretically create your own instance context provider, but if you want to create one that works just like the ones that WCF uses, you’ll need access to even more internal methods. So, the best solution seems to be once again to use reflection to call into some internals and create one of the standard instance context providers.
3. Because WCF makes sending raw HTTP messages rather cumbersome, we’ll create a custom message class to abstract the messy details.

Now, for the code. Here’s everything you need to serve custom HTTP help pages along with your service:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ServiceModel.Description;
using System.ServiceModel.Dispatcher;
using System.ServiceModel.Channels;
using System.ServiceModel;
using System.Reflection;

namespace CustomHelpPageBehavior
{
    class Program
    {
        static void Main(string[] args)
        {
            ServiceHost host = new ServiceHost(typeof(EchoService));
            host.AddServiceEndpoint(typeof(IEchoService), new BasicHttpBinding(), "http://localhost:8080/sample");
            host.Description.Behaviors.Add(new HelpPageBehavior() { Address = new EndpointAddress("http://localhost:8080/sample"), Content = "hello world!" });

            host.Open();

            Console.WriteLine("Press enter to exit...");
            Console.ReadLine();

            host.Close();

        }
    }

    [ServiceContract]
    public interface IEchoService
    {
        [OperationContract]
        string Echo(string text);
    }

    public class EchoService : IEchoService
    {
        public string Echo(string text)
        {
            return text;
        }
    }

    public class HelpPageBehavior : IServiceBehavior
    {
        public HelpPageBehavior()
        {
            HttpTransportBindingElement httpTransport = new HttpTransportBindingElement();
            httpTransport.GetType().GetProperty("Method", BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.SetProperty).SetValue(httpTransport, "GET", null);
            Binding = new CustomBinding(new WebMessageEncodingBindingElement() { MessageVersion = MessageVersion.None, ContentTypeMapper = new RawContentTypeMapper() }, httpTransport);
        }

        public void AddBindingParameters(ServiceDescription serviceDescription, System.ServiceModel.ServiceHostBase serviceHostBase, System.Collections.ObjectModel.Collection endpoints, System.ServiceModel.Channels.BindingParameterCollection bindingParameters)
        {

        }

        public Binding Binding
        {
            get;
            set;
        }

        public EndpointAddress Address
        {
            get;
            set;
        }

        class HttpGetContractFilter : MessageFilter
        {
            public override bool Match(Message message)
            {
                HttpRequestMessageProperty prop = (HttpRequestMessageProperty)message.Properties[HttpRequestMessageProperty.Name];
                if (prop != null)
                {
                    return prop.Method == "GET";
                }
                return false;
            }

            public override bool Match(MessageBuffer buffer)
            {
                using (Message message = buffer.CreateMessage())
                {
                    HttpRequestMessageProperty prop = (HttpRequestMessageProperty)message.Properties[HttpRequestMessageProperty.Name];
                    if (prop != null)
                    {
                        return prop.Method == "GET";
                    }
                    return false;
                }
            }
        }

        [ServiceContract]
        public interface IHtmlHelp
        {
            [OperationContract(Action = "*", ReplyAction = "*")]
            Message Get(Message message);
        }

        public class HtmlHelp : IHtmlHelp
        {
            public Message Get(Message message)
            {
                return new TextMessage(Content);
            }

            public string Content
            {
                get;
                set;
            }
        }

        public class OperationInvoker : IOperationInvoker
        {
            public OperationInvoker()
            {

            }

            public object[]  AllocateInputs()
            {
             	return new object[1];
            }

            public object  Invoke(object instance, object[] inputs, out object[] outputs)
            {
                outputs = new object[1];
             	outputs[0] = ((IHtmlHelp)instance).Get((Message)inputs[0]);
                return outputs[0];
            }

            public IAsyncResult  InvokeBegin(object instance, object[] inputs, AsyncCallback callback, object state)
            {
             	throw new NotImplementedException();
            }

            public object  InvokeEnd(object instance, out object[] outputs, IAsyncResult result)
            {
             	throw new NotImplementedException();
            }

            public bool  IsSynchronous
            {
            	get { return true; }
            }
        }

        public void ApplyDispatchBehavior(ServiceDescription serviceDescription, System.ServiceModel.ServiceHostBase serviceHostBase)
        {
            ChannelDispatcher dispatcher = null;

            if(dispatcher == null)
            {
                dispatcher = new ChannelDispatcher(Binding.BuildChannelListener(Address.Uri, "", new BindingParameterCollection()));
            }
            dispatcher.MessageVersion = MessageVersion.None;
            EndpointDispatcher endpointDispatcher = new EndpointDispatcher(Address, "Get", "http://tempuri.org/html");
            endpointDispatcher.AddressFilter = new HttpGetContractFilter();
            endpointDispatcher.ContractFilter = new MatchAllMessageFilter();
            endpointDispatcher.DispatchRuntime.Operations.Add(new DispatchOperation(endpointDispatcher.DispatchRuntime, "Get", "*", "*") { Invoker = new OperationInvoker(), DeserializeRequest = false, SerializeReply = false });
            endpointDispatcher.DispatchRuntime.SingletonInstanceContext = new InstanceContext(serviceHostBase, new HtmlHelp() { Content = Content });
            Type type = Assembly.GetAssembly(typeof(IReplyChannel)).GetType("System.ServiceModel.Dispatcher.SingletonInstanceContextProvider");
            endpointDispatcher.DispatchRuntime.InstanceContextProvider = ((IInstanceContextProvider)Activator.CreateInstance(type, BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public, null, new object[] { endpointDispatcher.DispatchRuntime }, System.Globalization.CultureInfo.CurrentCulture));
            endpointDispatcher.FilterPriority = 0;
            dispatcher.Endpoints.Add(endpointDispatcher);            

            serviceHostBase.ChannelDispatchers.Add(dispatcher);
        }

        public void Validate(ServiceDescription serviceDescription, System.ServiceModel.ServiceHostBase serviceHostBase)
        {

        }

        public string Content
        {
            get;
            set;
        }

        public class RawContentTypeMapper : WebContentTypeMapper
        {
            public override WebContentFormat GetMessageFormatForContentType(string contentType)
            {
                return WebContentFormat.Raw;
            }
        }

        public class TextMessage : Message
        {
            public TextMessage(string content)
            {
                Content = content;
                Properties[WebBodyFormatMessageProperty.Name] = new WebBodyFormatMessageProperty(WebContentFormat.Raw);
            }

            protected override void OnWriteBodyContents(System.Xml.XmlDictionaryWriter writer)
            {
                byte[] data = System.Text.UTF8Encoding.UTF8.GetBytes( Content );
                writer.WriteBase64(data, 0, data.Length );
            }

            public string Content
            {
                get;
                private set;
            }

            MessageHeaders _headers = new MessageHeaders(MessageVersion.None);
            public override MessageHeaders Headers
            {
                get
                {
                    return _headers;
                }
            }

            MessageProperties _properties = new MessageProperties();
            public override MessageProperties Properties
            {
                get
                {
                    return _properties;
                }
            }

            public override MessageVersion Version
            {
                get
                {
                    return MessageVersion.None;
                }
            }
        }
    }
}

“This specification defines an abstract data set called the XML Information Set (Infoset). Its purpose is to provide a consistent set of definitions for use in other specifications that need to refer to the information in a well-formed XML document.”

http://www.w3.org/TR/xml-infoset/

XML is so commonplace today that it is easy to overlook the importance of this statement. One of the core concepts behind XML is the idea of a logical infoset that says nothing about angle brackets and the textual representation that you and I will instantly recognize as an XML document. The logical infoset is little more than a tree of nodes which theoretically can be represented in any number of ways Understanding this is one of the keys to understanding WCF at a deeper level.

If you’ve worked with XML in the .NET framework, you know that there are multiple ways to deal with XML. .NET 1.0 gave us the most commonly used XML classes: the XmlDocument, the XmlReader and the XmlWriter.

If you take a look at the methods exposed by the XmlWriter class, you will notice a lot of what appear to be helper methods. Methods like WriteBase64 and WriteValue take non-text arguments like byte arrays and dates and encode the values into XML representations. For instance, take a look at the following code:

            using (Stream output = File.Create("output.txt"))
            {
                using (XmlWriter xmlWriter = XmlWriter.Create(output))
                {
                     xmlWriter.WriteStartElement("rawBytes");

                    byte[] rawBytes = new byte[1000];
                    byte[] data = new byte[] { 72, 101, 108, 108, 111, 32, 87, 111, 114, 108, 100, 33 };
                    data.CopyTo(rawBytes, 0);                    

                    xmlWriter.WriteBase64(rawBytes, 0, rawBytes.Length);
                    xmlWriter.WriteEndElement();
                }
            }

Executing this code will produce the following text in the output XML document:

<rawBytes>SGVsbG8gV29ybGQhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==</rawBytes>

No surprises here. Our data is base 64 encoded just like the method implies. However, as I said before, the XML infoset is logical and doesn’t define encoding. What if I had a lot of binary data that I wanted to send to an endpoint, and I didn’t want to waste all those extra bits with base 64 encoding? Maybe I would want to write that base 64 data out without any encoding to save space.

As it turns out, there is a specification for doing exactly that type of thing, which is known as MTOM. MTOM borrows some ideas from e-mail servers, which have been doing this type of thing forever with email attachments and brings the same concept to the XML world. MTOM splits a message up into “MIME parts” which can each be encoded a different way. One part of the message will contain the plain XML, and all the binary data will be moved to its own section, where we don’t have to worry about special characters and encoding. By telling .NET to create an MTOM XML writer instead, we can see how this works:

            using (Stream output = File.Create("output.txt"))
            {
                using (XmlWriter xmlWriter = XmlDictionaryWriter.CreateMtomWriter(output, Encoding.UTF8, Int32.MaxValue, "text/xml"))
                {
                    xmlWriter.WriteStartElement("rawBytes");

                    byte[] rawBytes = new byte[1000];
                    byte[] data = new byte[] { 72, 101, 108, 108, 111, 32, 87, 111, 114, 108, 100, 33 };
                    data.CopyTo(rawBytes, 0);                    

                    xmlWriter.WriteBase64(rawBytes, 0, rawBytes.Length);
                    xmlWriter.WriteEndElement();                 

                }
            }

Executing this code produces the following output:

MIME-Version: 1.0
Content-Type: multipart/related;type=”application/xop+xml”;boundary=”4f98bb98-f37b-412a-b90e-dbe8f939d214+id=1″;start=”<http://tempuri.org/0/634011443993914940>”;start-info=”text/xml”

–4f98bb98-f37b-412a-b90e-dbe8f939d214+id=1
Content-ID: <http://tempuri.org/0/634011443993914940>
Content-Transfer-Encoding: 8bit
Content-Type: application/xop+xml;charset=utf-8;type=”text/xml”

<rawBytes><xop:Include href=”cid:http%3A%2F%2Ftempuri.org%2F1%2F634011443993924705″ xmlns:xop=”http://www.w3.org/2004/08/xop/include”/></rawBytes>
–4f98bb98-f37b-412a-b90e-dbe8f939d214+id=1
Content-ID: <http://tempuri.org/1/634011443993924705>
Content-Transfer-Encoding: binary
Content-Type: application/octet-stream
Hello World!
–4f98bb98-f37b-412a-b90e-dbe8f939d214+id=1–

Notice that our XML chunk in the first part of the document has been replaced with a special “XOP” reference node which instructs the recipient that the data can be found in a MIME attachment, and the binary data is no longer base 64 encoded. This looks nothing like the first example and is certainly not the type of XML document you are used to seeing on a daily basis; however, it represents the same logical infoset as the first example. If we had an MTOM reader available (which we do), we could read this document and work with its content the same way as any other XML document.

So let’s extend this idea a little bit. Let’s suppose that we wanted to represent a raw binary file using an XML infoset. How would we represent it? The basic problem should be obvious: most files aren’t XML documents and most files aren’t encoded using MIME parts. But remember that XML and MIME are nothing more than different ways to encode the infoset. If it’s possible to write the binary data as a MIME part, there is no reason we can’t just write the binary data and exclude all the MIME wrappers. To do that, we can create a simple XmlWriter implementation (we’ll leave a lot of the methods unimplemented since our schema doesn’t support anything but our raw binary format):

    public class RawXmlWriter : XmlWriter
    {
        public RawXmlWriter(Stream stream)
        {
            _stream = stream;
        }

        Stream _stream;
        public override void WriteBase64(byte[] buffer, int index, int count)
        {
            _stream.Write(buffer, index, count);
        }

        public override void WriteStartElement(string prefix, string localName, string ns)
        {
            if (localName != "rawBytes")
            {
                throw new InvalidOperationException("This xml writer only supports raw binary data");
            }
        }

        public override void WriteEndElement()
        {

        }

        public override void Close()
        {
            _stream.Close();
        }
   }

The rest of the methods, we’ll leave unimplemented, since we are creating a writer which supports a very limited schema. Now we change our code to use our Raw XML Writer:

            using (Stream output = File.Create("output.txt"))
            {
                using (XmlWriter xmlWriter = new RawXmlWriter(output))
                {
                    xmlWriter.WriteStartElement("rawBytes");

                    byte[] rawBytes = new byte[1000];
                    byte[] data = new byte[] { 72, 101, 108, 108, 111, 32, 87, 111, 114, 108, 100, 33 };
                    data.CopyTo(rawBytes, 0);                    

                    xmlWriter.WriteBase64(rawBytes, 0, rawBytes.Length);
                    xmlWriter.WriteEndElement();                 

                }
            }

And if we take a look at the file on disk, we see the raw bytes from our array written to disk. Creating a RawXmlReader would allow us to read in any file from disk and use its data anywhere we can use an XmlReader.

So what does this have to do with WCF? Well, this is exactly how WCF works under the covers to support multiple forms of message encoding while using infosets to represent the data. When using bindings such as net.tcp, a different implementation of XmlReader and XmlWriter are plugged in which use an optimized XML infoset representation that significantly reduces the overhead imposed by a standard text encoder. When sending data using the REST features of WCF, the WebMessageEncoder uses the same strategy we employed in the final example to read and write raw binary data.

The abstract XML infoset is a powerful concept. By always remembering that the infoset itself is logical, we can enable our application to read or write any format imaginable with a common interface and a simple tree representation.

If you are familiar with ASP.NET, you have probably heard of a little class called IRequestHandler. In ASP.NET, if you wanted to create a handler that simply streamed a file from disk, you might write a little code like this:

    public class FileRequestHandler : IHttpHandler
    {
        #region IHttpHandler Members

        public bool IsReusable
        {
            get { return false;  }
        }

        public void ProcessRequest(HttpContext context)
        {
            context.Response.WriteFile(context.Request.PhysicalPath);
        }

        #endregion
    }

This should not be scary at all. Now… what if we wanted to host a simple web server inside our own application and we wanted to be able to use WCF to call into the interface? It takes a little WCF ninjitsu to make it work, but that’s what this blog is for.

The first step is creating a binding that will allow raw HTTP communication. To do this, we will create an instance of the CustomBinding class. Most of the bindings that you might be familiar with, such as basicHttpBinding or netTcpBinding hide the internals of WCF and don’t let you have any clue what is going on under the covers. CustomBinding is not one of those classes. The CustomBinding class allows you to pick and choose transports, security, message encoding (known in WCF terms as “BindingElements”) and combine them to do things that the standard bindings won’t let you do. In this case, we want to tell WCF to combine the HttpTransportBindingElement and the WebMessageEncodingBindingElement. In .NET 4.0 we have a better option… but most people aren’t using .NET 4.0 today so I’ll stick with .NET 3.5 for now. Another possibility would be to write a custom message encoder, but I’ll try to reuse as much of the built-in classes as possible. One little quirk about the WebMessageEncodingBindingElement is that it defaults to POX support, not raw HTTP. We can change that by adding a custom ContentTypeMapper implementation. To facilitate this process, I’ve created a BindingFactory class:

 public static class BindingFactory
    {
        public static Binding CreateRawHttpBinding()
        {
            HttpTransportBindingElement transport = new HttpTransportBindingElement();
            return new CustomBinding(CreateEncoder(), transport);
        }

        public static WebMessageEncodingBindingElement CreateEncoder()
        {
            WebMessageEncodingBindingElement encoding = new WebMessageEncodingBindingElement();
            encoding.ContentTypeMapper = new RawContentTypeMapper();
            return encoding;
        }

        class RawContentTypeMapper : WebContentTypeMapper
        {
            public override WebContentFormat GetMessageFormatForContentType(string contentType)
            {
                return WebContentFormat.Raw;
            }
        }
    }

The second thing we are going to need is a ServiceContract. If you read just about any documentation on WCF REST support, you will be lead to believe that you need to add special service behaviors for Url templates and HTTP verbs. Personally, I think all of that nonsense is crap, so we won’t do that. Instead, we’ll create a generic contract that can receive any message. Note that this contract is not REST specific. You could actually use the contract to do raw SOAP messaging as well. The way we tell WCF to allow any message to be handled by our contract is to add a method that accept a Message, returns a Message, and has it’s action and reply action set to “*”. This is what it looks like:

 [ServiceContract]
    public interface IWebRequestHandler
    {
        [OperationContract(Action="*", ReplyAction="*")]
        Message Request(Message message);
    }

When a request comes into our service, we’ll want the HTTP specific properties from the request to obtain things like the HTTP method and query string. To obtain the HTTP specific information about the request, we can get an HttpRequestMessageProperty from the properties collection of the message. This is pretty simple:

  HttpRequestMessageProperty property = (HttpRequestMessageProperty)message.Properties[HttpRequestMessageProperty.Name];

When we create a response message, we’ll add an HttpResponseMessageProperty for HTTP specific information. To write the response we’ll create a simple custom message class that can be used to represent our raw binary data. There are two tricks here. The first is that we are adding a WebBodyFormatMessageProperty to the message. This is required because of our choice of MessageEncoder and instructs the message encoder that we will be writing raw binary data. The second trick is that we write out the content as Base64 data. The XmlDictionaryWriter implementation that will be created by the MessageEncoder as a result of the property we have added will write out the Base64 data as raw binary data instead of encoding it. This might seem odd, but there is a very good reason that it works this way. I’ll save that for a later date.

        class RawMessage : Message
        {
            public RawMessage(byte[] data)
            {
                _data = data;

                WebBodyFormatMessageProperty property = new WebBodyFormatMessageProperty(WebContentFormat.Raw);
                Properties.Add(WebBodyFormatMessageProperty.Name, property);
            }

            byte[] _data;

            MessageHeaders _headers = new MessageHeaders(MessageVersion.None);
            public override MessageHeaders Headers
            {
                get { return _headers; }
            }

            protected override void OnWriteBodyContents(System.Xml.XmlDictionaryWriter writer)
            {
                writer.WriteBase64(_data, 0, _data.Length);
            }

            MessageProperties _properties = new MessageProperties();
            public override MessageProperties Properties
            {
                get { return _properties; }
            }

            public override MessageVersion Version
            {
                get { return MessageVersion.None;  }
            }
        }

Now we are ready to move on to our simple server implementation. Note that we’ve marked up the implementation of our interface with an attribute to tell WCF to accept requests to any child path below our endpoint address.

 [ServiceBehavior(AddressFilterMode=AddressFilterMode.Prefix, InstanceContextMode=InstanceContextMode.Single, ConcurrencyMode=ConcurrencyMode.Multiple)]
    public abstract class WebRequestHandler : IWebRequestHandler
    {
        public WebRequestHandler(Uri address)
        {
            // Ensure there is a trailing slash to our URL to so that MakeRelativeUri will work when we map the URL to a relative path.
            if (!address.ToString().EndsWith("/"))
            {
                address = new Uri(address + "/");
            }
            _address = address;
        }

        Uri _address;        

        MessageEncoder _webEncoder = BindingFactory.CreateEncoder().CreateMessageEncoderFactory().Encoder;

        protected abstract void ProcessRequest(Uri address, HttpRequestMessageProperty requestProperty, TextReader requestBody, HttpResponseMessageProperty responseProperty, TextWriter responseBody);        

        protected string GetRelativePath(Uri address)
        {
            string relativePath = address.LocalPath;
            relativePath = _address.MakeRelativeUri(address).ToString();
            int qIndex = relativePath.IndexOf('?');
            if (qIndex != -1)
            {
                relativePath = relativePath.Substring(0, qIndex);
            }
            return relativePath;
        }

        public System.ServiceModel.Channels.Message Request(System.ServiceModel.Channels.Message message)
        {
            using (MemoryStream responseStream = new MemoryStream())
            {
                using (TextWriter writer = new StreamWriter(responseStream))
                {
                    using (MemoryStream requestStream = new MemoryStream())
                    {
                        _webEncoder.WriteMessage(message, requestStream);
                         byte[] requestData = requestStream.ToArray();

                        using (TextReader reader = new StreamReader(new MemoryStream(requestData, false)))
                        {
                            HttpRequestMessageProperty requestProperty = (HttpRequestMessageProperty)message.Properties[HttpRequestMessageProperty.Name];

                            HttpResponseMessageProperty responseProperty = new HttpResponseMessageProperty();

                            ProcessRequest(message.Headers.To, requestProperty, reader, responseProperty, writer);

                            writer.Flush();
                            Message responseMessage = new RawMessage(responseStream.ToArray());
                            responseMessage.Properties[HttpResponseMessageProperty.Name] = responseProperty;
                            return responseMessage;
                        }
                    }
                }
            }
        }
    }

So now we have a basic web server class that we can extend. Hooking into the ASP.NET side of things is actually fairly messy and complex in comparison. I’ve included a very simple implementation in the sample project which contains enough logic to execute the simple file handler that this post started with. So there you have it. A raw HTTP host that can respond to web requests and serve up content using WCF.

[Download Sample Project: WebServer.zip]

Key Parts

There are four key parts to the message class:

• Version - The version property contains information about the SOAP and Addressing versions used by the message. WCF fully supports use of non-SOAP messages for which this property is will be None to indicate the lack of any special formatting.
• Properties - Message properties contain processing information about the message which will not be written to the underlying transport stream as part of the message content. One example of what message properties can be used for is controlling things like HTTP verbs and status codes.
• Headers - A collection of message headers. A few common headers such as To and Action can be accessed via shortcut properties in the headers collection.
• Body - You can’t actually access the message body because the Message class abstraction is mean to be used as if the content of the Message was a stream.

It’s Abstract

This will come as a surprise to many people, because the WCF framework does a very good job of hiding this fact, but the Message class itself is an abstract class. So put away any preconceived notions you might have had about how WCF at it’s core can only be used for web services and XML based communication. The fact is that you could create a message class backed directly by a raw binary array if you didn’t want any kind of performance hit for loading the data… as a matter of fact you probably wouldn’t want to even waste your time doing that, because WCF does exactly that when you are using many of the default settings! Actually… it does it even more efficiently than you would probably do it on your own by taking advantage of buffer managers to reduce the number of allocations that need to be made as messages are being created and disposed. So, despite the fact that the underlying abstraction is streaming, WCF actually buffers messages into a byte array by default to allow for higher performance.

It’s Streaming

Once you read the message, it cannot be read again. For this reason, all custom message classes must also provide a MessageBuffer implementation. I won’t talk much about the MessageBuffer class at this point, other than to say that it is also abstract and it is responsible for creating additional “copies” of the message. I say “copies” because the default implementations that are most commonly used by the standard bindings won’t actually “copy” anything. They just return another instance backed by the same internal byte array. This makes for ultra efficient message copying, but is only possible because of another trait of the message… The reason Message implementers must provide their own MessageBuffer implementations is so that the copy operation itself can be as optimized as possible.

It’s Immutable

Well… sort of. The properties and headers of the message can be modified at will, making things like routing logic and header processing much easier to deal with, but the message body itself cannot be modified using the Message or MessageBuffer classes. For this reason, many hooks  in the WCF internals where a Message might need to by modified will pass the message as a ref parameter so it can be swapped for another message.

It’s Not XML

The last basic thing you need to know about the Message class which I already touched on, but should make clear again… the Message class does have to not represent XML data! This may seem like a strange statement if you’ve looked casually at the methods provided by the message class. However, this is only due to the unfortunate naming that the WCF team chose for XmlDictionaryReader and XmlDictionaryWriter, which have a lot of methods for reading and writing XML data, but fully support reading and writing raw binary content as well.