I want to write an IErrorHandler implementation that will handle AuthenticationException instances (a proprietary type), and then in the implementation of ProvideFault provide a traditional Http Response with a status code of 403 as the fault message.

So far I have my first best guess wired into a service, but WCF appears to be ignoring the output message completely, even though the error handler is being called.

At the moment, the code looks like this:

public class AuthWeb403ErrorHandler : IErrorHandler
{
  #region IErrorHandler Members
  public bool HandleError(Exception error)
  {
    return error is AuthenticationException;
  }

  public void ProvideFault(Exception error, MessageVersion version, ref Message fault)
  {
    //first attempt - just a stab in the dark, really
    HttpResponseMessageProperty property = new HttpResponseMessageProperty();
    property.SuppressEntityBody = true;
    property.StatusCode = System.Net.HttpStatusCode.Forbidden;
    property.StatusDescription = "Forbidden";

    var m = Message.CreateMessage(version, null);

    m.Properties[HttpResponseMessageProperty.Name] = property;
    fault = m;
  }
  #endregion
}

With this in place, I just get the standard WCF html 'The server encountered an error processing the request. See server logs for more details.' - which is what would happen if there was no IErrorHandler. Is this a feature of the behaviours added by WebServiceHost? Or is it because the message I'm building is simply wrong!? I can verify that the event log is indeed not receiving anything.

My current test environment is a WebGet method (both XML and Json) hosted in a service that is created with the WebServiceHostFactory, and Asp.Net compatibility switched off. The service method simply throws the exception in question.