Evidentially the request message isn't guaranteed to be around by the time you get to your response code. I found out this the hard way when I was getting sporadic failures accessing properties of the IncomingWebRequestContext in response code. To get around this I just stashed info (While in request code) I was interested in, in the outgoing message properties. Then I retrieve these properties in my response code.

Using the outgoing message properties approach is pretty easy. To give you a little background, I have an error handler behavior that attaches a specified error handler to all channel dispatchers in a particular service. I also have a custom error handler that logs exceptions to a specified object that implemented a particular logging interface. This error handler passes the request http info to the logger. Originally I was directly accessing the IncomingWebRequestContext in the HandleError method of the error handler to get this request info and would sporadically get the error in the title. Now in my error handler behavior I'm adding a message inspector that will add the request http info to the outgoing message properties (I'm piggy backing off the error handler behavior to do this because they are so closely related):

public class ErrorHandlerBehavior : IServiceBehavior
{
    public const string HttpRequestInformationProperty = "HttpRequestInformation";

    public void ApplyDispatchBehavior(
            ServiceDescription serviceDescription, 
            ServiceHostBase serviceHostBase)
    {
       foreach (ChannelDispatcher dispatcher in 
                serviceHostBase.ChannelDispatchers)
       {
            // Add the error handler...

            // Add the parameter inspector that gets the request info and
            // stores it in the outgoing message properties
            foreach (EndpointDispatcher endpoint in dispatcher.Endpoints)
                  endpoint.DispatchRuntime.MessageInspectors.Add(
                       new HttpRequestInformationInspector());
       }
    }
}

So now error handlers have this info at their disposal. Then in the message inspector we grab the http request info and stash it in the outgoing message properties:

private class HttpRequestInformationInspector : IDispatchMessageInspector   
{
    public object AfterReceiveRequest(ref System.ServiceModel.Channels.Message request, IClientChannel channel, InstanceContext instanceContext)
    {
        HttpRequestInformation info = new HttpRequestInformation();

        string contentLengthHeader =
            WebOperationContext.Current.IncomingRequest.Headers[HttpRequestHeader.ContentLength];

        long contentLength;
        if (!string.IsNullOrEmpty(contentLengthHeader))
            long.TryParse(contentLengthHeader, out contentLength);
        else
            contentLength = -1;

        info.ContentLength = contentLength;
        info.Uri = OperationContext.Current.IncomingMessageHeaders.To;
        info.Method = WebOperationContext.Current.IncomingRequest.Method;
        info.ContentType = WebOperationContext.Current.IncomingRequest.ContentType;
        info.Accept = WebOperationContext.Current.IncomingRequest.Accept;
        info.UserAgent = WebOperationContext.Current.IncomingRequest.UserAgent;
        info.Headers = WebOperationContext.Current.IncomingRequest.Headers;

        OperationContext.Current.OutgoingMessageProperties.Add(
            HttpRequestInformationProperty, info);
        return null;
    }

    public void BeforeSendReply(ref System.ServiceModel.Channels.Message reply, object correlationState) { }
}

public class HttpRequestInformation
{
    public Uri Uri { get; set; }
    public string Method { get; set; }
    public string ContentType { get; set; }
    public long ContentLength { get; set; }
    public string Accept { get; set; }
    public string UserAgent { get; set; }
    public WebHeaderCollection Headers { get; set; }
}

Note that I'm manually grabbing the content length from the headers. Interestingly the content length header may not always be present. And its absence may not mean that the content length is zero (That's why I return a negative number if it is absent). The problem is the IncomingWebRequestContext ContentLength property does not check for the existence of the header before it parses it. So if its not there (Which is what's going to happen with a GET request) it will throw a null ref exception (Which can be confusing). I have submitted feedback here it you want to read more about this and Microsoft's response.

So now it's available in response code:

public bool HandleError(Exception error)
{
    HttpRequestInformation info;

    if (OperationContext.Current.OutgoingMessageProperties.ContainsKey(
        ErrorHandlerBehavior.HttpRequestInformationProperty))
        info = (RequestInformation)OperationContext.Current.OutgoingMessageProperties[
            ErrorHandlerBehavior.HttpRequestInformationProperty];
    else
        info = new RequestInformation();

    LogHandler.Write(error, info);
    return true;
}

Do you know of a better way to handle this? If so, please leave a comment as I'm not 100% satisfied with this approach and would be interested in a simpler alternative.