Question

I have built a request logging DelegatingHandler using the details in this blog post.

I do not want to read the request or response bodies (doubling-up this work seems silly on a potentially high-volume web service); all I want to do is assign each request a unique ID, log the URI and headers; write the request ID to the response in another header and then log the response (Success/fail) and any exception that occurred.

protected override System.Threading.Tasks.Task<HttpResponseMessage> 
  SendAsync(HttpRequestMessage request, 
  System.Threading.CancellationToken cancellationToken)
{
  DateTime receivedUTC = DateTime.UtcNow;

  //I use the Request properties to persist a Request's ID
  var requestID = request.GetRequestUID();
  if (requestID == null)
    requestID = request.SetRequestUID();

  //grab the base response task
  var baseResult = base.SendAsync(request, cancellationToken);

  return baseResult.ContinueWith(innerTask =>
  {
    var tcs = new TaskCompletionSource<HttpResponseMessage>();

    //note I've got rid of SynchronizationContext code out of this
    //to keep it shorter

    //construct the log packet
    LogData toLog = new LogData()
        {
          ReceivedUTC = receivedUTC,
          Request = request,
          RequestID = requestID,
        };

    //get the response
    try
    {
      tcs.SetResult(innerTask.Result);
      //NOTE - If this request actually fails response serialization,
      //       Then the above result will actually look fine, because
      //       The error hasn't occurred yet!
      toLog.Response = innerTask.Result;
      //this adds a header
      AddRequestIDToResponse(toLog.Response, requestID);
    }
    catch (Exception ex)
    {
      tcs.TrySetException(ex);
      toLog.Ex = ex;
    }

    //fire the logging call asynchronously (code elided, just some DB work)
    Task.Factory.StartNew(() => Log(toLog));
    return tcs.Task;
  }).Unwrap();
}

This all works absolutely fine for nearly all requests, except when an exception occurs whilst the ObjectContent returned from an action method gets serialized to the response.

If this happens, the above code has already fired, and the response message it sees in the try/catch block above appears as a normal 200 with the ObjectContent containing the object that will eventually fail serialization. That does makes sense – since serialization to the response body hasn’t occurred yet.

How do I change this code (without forcing a read on the ObjectContent) to ensure that the response message I see is the actual message that the client receives, after content formatting has taken place? Should I be looking at a different extensibility point?

Answer 1

As a tentative answer until someobody (hopefully) comes along and proves me wrong; it would appear that this is going to be nigh on impossible within the Web API pipeline itself without copying and pasting a huge amount of code.

The content serialization is triggered at the very top of the Web API pipeline – in the HttpControllerHandler, where the HttpContent is copied to the underlying HttpResponse‘s OutputStream in an internal static method called HttpControllerHandler.ConvertResponse. There aren’t enough extensibility points on the class itself to be able to inject a task in the correct place to be able to log the actual response within the Web API pipeline.

So I’m faced with:

• Lifting HttpControllerHandler in it’s entirety from the source
  code and importing it to my project (and all the internals it uses,
  which is not a nice thought), then customising it accordingly.

• Just force serialization early and catch the exception – I can log
  the exception but not the response. There is one slight issue with
  this, though – writing the request ID to the response is very
  important, and when these formatting exceptions occur, the ID doesn’t
  get written because HttpControllerHandler replaces the entire
  response with it’s error response!

• Logging requests at the next level up from the Web API. This
  isn’t ideal because I only want Web API requests logged; and
  also the logging code has a dependency on the current request’s
  HttpConfiguration object in order to grab a request-specific DI
  container for resolving database connections (its a multi-tenant web
  service).

Ultimately the only real option is the last one – to do the work at the IIS or Asp.Net level. So despite all those extensibility points in the Web API – you actually can’t implement a ‘complete’ logging solution within it – that’s really disappointing.