HTTP Logging in ASP.NET 6.0

ASP.NET 6.0 is finally here! Don’t let smaller features like HTTP Logging get lost in the hype – sometimes they add the most value to real development.

ASP.NET 6.0 is finally here, and it brings with it all kinds of amazing updates.  However, one of the most underrated new features is the new built-in HTTP Logging functionality.  This feature allows you to print out the raw HTTP Requests and Responses your app manages straight to the console.  You could of course achieve this in the past, but it required manual setup and code, or external packages that might not be exactly what you want.  HTTP Logging is now built right into the framework through a convenient Middleware component.

For this example we’ll just use a basic out of the box Web API template, but it works with other ASP.NET project types as well.

Setting up HTTP logging is extremely easy if you follow these steps.

1 – Add the logging middleware to your Program.cs file.

I recommend adding this middleware at the front of your pipeline in case other middleware also modify the request – that way their changes will be picked up in the logs.

app.UseHttpLogging();

IMPORTANT NOTE: An easy “gotcha” of this feature is that you must have your logging level set to “information” in the appsettings.Development.json file of your solution.  Remember, you an click the arrow next to appsettings.json to see this environment specific file. By default the log level is set to warning, which means the HTTP logs won’t show up, which can give the illusion that its not working. Make sure you adjust this!  I missed this at first and it took me a moment to figure out why this wasn’t working. Your appsettings.Development.json should look like this:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Information"
    }
  }
}

Next, start your app through Visual Studio.  On the Swagger UI page that loads, try executing a sample request, and you should see logs similar to what’s shown here in your terminal window.

Our request URL and headers are now being logged automatically! Magic. Of course, there are also plenty of customization options for this.

2- Add configurations

We can register an HTTP Logging Options services with our app to add plenty of configurations.  This can be done on our builder object above where we construct the middleware pipeline, so it should look something like the code below.

builder.Services.AddControllers();
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

// Logging configuration can go here!
builder.Services.AddHttpLogging(httpLogging =>
{
httpLogging.RequestHeaders.Add("Demo Request Header");
httpLogging.ResponseHeaders.Add("Demo Response Header");
httpLogging.RequestBodyLogLimit = 4096;
httpLogging.ResponseBodyLogLimit = 4096;
});

var app - builder.Build();

This sample shows some of the common configurations, but there are additional options beyond what those listed here.  LoggingFields in particular is interesting, because it allows us to log the full body on data driven requests, such as POST and PUT operations.  We can also add headers, limit the body log size, and so on. You can use intellisense to browse the other options.

Restart your app with these changes and test out a sample POST request – you should see the request body logged now as well.

3 – Security and Performance considerations

HTTP Logging can negatively impact the performance of your app.  You may only want to enable this in development environments and avoid using this in production, as there are often better ways to achieve this functionality there.  HTTP Logging can also have considerable security considerations – especially when logging the Body of the request.  Make sure these logs are not printed out anywhere that might permanently store or aggregate such data.

So in summary, this feature can be really useful and lower our dependencies on tools like Postman or the browser tools. It can be a hassle to keep switching to additional tools just to view raw HTTP requests, so this can be a real time saver when building APIs.

More ASP.NET 6.0 content soon, enjoy!

0 Shares:
You May Also Like