ASP.NET - ASP.NET Core HTTP Logging Middleware

HTTP logging is an important feature in ASP.NET Core for observing HTTP traffic handled by an application. It allows developers to record information about incoming HTTP requests and outgoing HTTP responses, making it easier to understand how an application is behaving, diagnose problems, and investigate unexpected request or response behavior. Unlike ordinary application logging, which usually records events generated by application code, HTTP logging focuses specifically on the communication occurring at the HTTP layer. Microsoft describes HTTP logging as middleware capable of logging request information, response information, headers, and, when configured, request and response bodies.

1. What Is HTTP Logging Middleware?

ASP.NET Core applications process HTTP requests through a middleware pipeline. Middleware components can inspect a request, perform some operation, pass the request to the next component, and then inspect the resulting response.

HTTP Logging Middleware works within this pipeline. When a client sends a request, the middleware can record details such as the HTTP method, request path, protocol, headers, and other selected information. After the application processes the request, the middleware can also record response information such as the status code, headers, and optionally the response body. 

For example, suppose a client sends:

GET /api/products/25

The HTTP log could provide information similar to:

Request:
Method: GET
Path: /api/products/25
Protocol: HTTP/2

Response:
StatusCode: 200

This gives developers a clear view of what reached the application and what the application returned.

2. Why HTTP Logging Is Useful

HTTP logging is particularly useful when diagnosing problems that are difficult to reproduce through application-level debugging.

Consider an API that occasionally returns a 400 Bad Request. Application logs might indicate that a validation operation failed, but HTTP logging can provide additional information about the request that caused the failure.

HTTP logging can help developers answer questions such as:

  • Which endpoint was requested?

  • What HTTP method was used?

  • What status code was returned?

  • Which headers were sent?

  • How long did the request take?

  • Was a particular request body responsible for a problem?

  • Did the application return an unexpected response?

  • Which requests are reaching a particular endpoint?

Microsoft specifically notes that HTTP logging can be configured to log all requests and responses or only selected information from them. 

3. Enabling HTTP Logging

HTTP logging is registered using AddHttpLogging and activated in the middleware pipeline with UseHttpLogging.

A basic configuration looks like this:

using Microsoft.AspNetCore.HttpLogging;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddHttpLogging(options =>
{
});

var app = builder.Build();

app.UseHttpLogging();

app.MapGet("/", () => "Hello World!");

app.Run();

AddHttpLogging registers the HTTP logging services, while UseHttpLogging adds the middleware to the request-processing pipeline. 

The order of middleware is important. For example, if UseHttpLogging() is placed after UseStaticFiles(), requests for static files are not included in HTTP logging. If logging of those requests is required, the HTTP logging middleware needs to be positioned before the static-file middleware. 

4. What Information Can Be Logged?

HTTP Logging Middleware provides control over which parts of HTTP communication are recorded.

Important categories include:

Request information

This can include:

  • HTTP method

  • Request path

  • Protocol

  • Request headers

  • Request body, when configured

For example:

Request:
GET /api/customers/10
Protocol: HTTP/2

Response information

Response logging can include:

  • Status code

  • Response headers

  • Response body, when configured

  • Request/response duration, depending on configuration

For example:

Response:
StatusCode: 200

Headers

Headers contain additional information about an HTTP request or response. However, ASP.NET Core does not automatically treat every header value as something that should be exposed in logs. Specific request and response headers can be selected for logging through configuration.

5. Configuring Logging Fields

The LoggingFields property controls what information HTTP Logging Middleware records.

For example:

builder.Services.AddHttpLogging(options =>
{
    options.LoggingFields = HttpLoggingFields.All;
});

This requests logging of all supported HTTP logging fields.

However, logging everything is not always a good production strategy. Logging request and response bodies can generate a large amount of data and can negatively affect application performance. Microsoft recommends considering the performance impact before enabling extensive body logging. 

A more selective configuration is often preferable:

builder.Services.AddHttpLogging(options =>
{
    options.LoggingFields =
        HttpLoggingFields.RequestPropertiesAndHeaders |
        HttpLoggingFields.ResponsePropertiesAndHeaders;
});

This approach focuses on useful metadata without automatically logging large request and response bodies.

6. Logging Request and Response Bodies

One of the more powerful capabilities of HTTP Logging Middleware is the ability to log request and response bodies.

For example, an API might receive:

{
    "name": "John",
    "department": "Sales"
}

Body logging can help developers determine exactly what information was submitted to an endpoint.

However, body logging should be used carefully. Request and response bodies may contain passwords, authentication tokens, personal information, financial information, or other confidential data.

There can also be a performance cost because the application has to process and record additional data. Microsoft specifically warns that logging request and response bodies can reduce application performance. 

For this reason, body logging is generally more appropriate for controlled development or troubleshooting scenarios than unrestricted production logging.

7. Limiting Body Size

ASP.NET Core provides configuration options for limiting how much of a request or response body is logged.

For example:

builder.Services.AddHttpLogging(options =>
{
    options.LoggingFields = HttpLoggingFields.All;

    options.RequestBodyLogLimit = 4096;
    options.ResponseBodyLogLimit = 4096;
});

Here, the application limits the amount of request and response body data considered for logging.

This is useful when an application handles large payloads. Without reasonable limits, HTTP logs can become unnecessarily large and difficult to manage.

8. Logging Specific Headers

Applications can selectively identify headers whose values should be logged.

For example:

builder.Services.AddHttpLogging(options =>
{
    options.RequestHeaders.Add("User-Agent");
    options.ResponseHeaders.Add("Content-Type");
});

This allows the application to capture specific header values instead of indiscriminately logging every header.

Selective header logging is especially important because HTTP headers can contain sensitive information. Microsoft notes that header values are logged only for header names included in the configured collections. 

9. Logging Level Configuration

After configuring HTTP logging, the appropriate logging category and level must be enabled so the messages are visible.

For development, an application can configure the HTTP logging middleware category in appsettings.Development.json:

{
  "Logging": {
    "LogLevel": {
      "Microsoft.AspNetCore.HttpLogging.HttpLoggingMiddleware": "Information"
    }
  }
}

The Information level allows HTTP logging messages to appear in the application's configured logging output. 

10. Combining Request and Response Logs

ASP.NET Core also provides the CombineLogs option.

builder.Services.AddHttpLogging(options =>
{
    options.LoggingFields = HttpLoggingFields.All;
    options.CombineLogs = true;
});

When enabled, information associated with a request and its corresponding response can be consolidated into one log entry at the end of processing. This can make individual transactions easier to inspect because the request, response, and duration can be considered together. 

11. Endpoint-Specific HTTP Logging

HTTP logging does not have to be configured identically for every endpoint.

ASP.NET Core supports endpoint-specific configuration through the HttpLogging attribute and WithHttpLogging extension method. Endpoint-specific configuration can override global HTTP logging configuration. 

This is useful when only certain endpoints require additional diagnostic information.

For example, an application might use normal logging for most endpoints but enable more detailed logging for a particular API that is currently being investigated.

12. HTTP Logging Interceptors

For more advanced scenarios, ASP.NET Core provides IHttpLoggingInterceptor.

An interceptor can inspect a request or response and dynamically influence what gets logged. It can, for example:

  • Disable logging for selected requests.

  • Modify logging fields.

  • Redact information.

  • Add custom information to logs.

  • Apply different logging behavior depending on the request.

Microsoft documents that interceptors can further modify the logging configuration after global and endpoint-specific configuration has been applied. 

This makes interceptors useful for applications that require fine-grained control over HTTP logging.

13. Protecting Sensitive Information

Security is one of the most important considerations when implementing HTTP logging.

An HTTP request can contain sensitive information such as:

Authorization: Bearer <token>

or:

{
    "username": "john",
    "password": "secret"
}

Logging such information could expose credentials or personal data to anyone who has access to the log files.

Microsoft explicitly warns that HTTP logging can potentially record personally identifiable information and recommends avoiding the logging of sensitive information. ASP.NET Core also provides redaction capabilities for HTTP logging.

Therefore, developers should carefully decide:

  • Which headers are logged.

  • Whether request bodies are logged.

  • Whether response bodies are logged.

  • Which endpoints require detailed logging.

  • How long logs are retained.

  • Who has access to logs.

14. Redacting Sensitive Data

Modern ASP.NET Core versions provide HTTP logging redaction capabilities.

A simplified configuration can include:

builder.Services.AddRedaction();

builder.Services.AddHttpLoggingRedaction(options =>
{
});

Redaction allows sensitive information to be removed or replaced before it reaches the log output.

This is particularly valuable for applications dealing with customer information, authentication data, payment information, or other confidential content. 

15. Performance Considerations

HTTP logging introduces additional work into the request-processing pipeline.

The performance impact is usually greater when applications log:

  • Large request bodies.

  • Large response bodies.

  • Many headers.

  • A very high volume of requests.

For a high-traffic application, logging every request and every response body can produce enormous log volumes.

A better strategy is often to log essential metadata by default and enable detailed logging only when required for troubleshooting.

Microsoft specifically recommends testing the performance impact of the selected HTTP logging properties, particularly when body logging is enabled. 

16. HTTP Logging in Development and Production

A practical application should generally use different logging strategies depending on its environment.

During development, detailed HTTP logging can be useful because developers are actively investigating application behavior.

For example:

Development
Request headers: Yes
Response headers: Yes
Request body: Sometimes
Response body: Sometimes
Detailed diagnostics: Yes

In production:

Production
Request metadata: Yes
Response metadata: Yes
Request body: Usually limited
Response body: Usually limited
Sensitive information: Redacted

The exact configuration depends on the application's security, compliance, debugging, and operational requirements.

17. Difference Between Application Logging and HTTP Logging

It is important not to confuse general application logging with HTTP logging.

Application logging records events generated by application components.

For example:

logger.LogInformation("Customer {Id} was created", customerId);

HTTP logging instead focuses on the HTTP interaction:

POST /api/customers
StatusCode: 201

They complement each other.

Application logging can explain what the application did internally, while HTTP logging can show what entered and left the application.

18. Practical Example

A basic ASP.NET Core application with controlled HTTP logging could be configured as follows:

using Microsoft.AspNetCore.HttpLogging;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddHttpLogging(options =>
{
    options.LoggingFields =
        HttpLoggingFields.RequestPropertiesAndHeaders |
        HttpLoggingFields.ResponsePropertiesAndHeaders;

    options.RequestHeaders.Add("User-Agent");
    options.ResponseHeaders.Add("Content-Type");
});

var app = builder.Build();

app.UseHttpLogging();

app.MapGet("/products/{id}", (int id) =>
{
    return Results.Ok(new
    {
        Id = id,
        Name = "Laptop"
    });
});

app.Run();

When a client requests:

GET /products/10

the middleware can record important request and response information without automatically recording the entire response body.

This illustrates a useful principle: HTTP logging should provide enough information to understand application behavior without unnecessarily recording sensitive or excessive data.

19. Advantages of HTTP Logging Middleware

HTTP Logging Middleware provides several important advantages.

Improved troubleshooting: Developers can identify what requests reached the application and how the application responded.

Better API diagnostics: Status codes, headers, paths, and other HTTP information can help diagnose API problems.

Flexible configuration: Developers can select which parts of HTTP communication are logged.

Endpoint-specific control: Detailed logging can be enabled for selected endpoints rather than the entire application.

Security controls: Sensitive information can be redacted, and unnecessary logging can be avoided.

Integration with ASP.NET Core logging: HTTP logs work within the broader ASP.NET Core logging infrastructure.

20. Limitations and Precautions

HTTP logging should not be treated as a replacement for complete application observability.

It primarily describes HTTP communication. It does not automatically explain every internal operation performed by the application.

Developers should also avoid excessive logging because it can:

  • Increase storage requirements.

  • Increase processing overhead.

  • Make important information harder to find.

  • Expose sensitive information.

  • Increase operational costs.

Therefore, effective HTTP logging requires a balance between diagnostic usefulness, performance, security, and storage requirements.

Conclusion

ASP.NET Core HTTP Logging Middleware provides a structured way to observe incoming HTTP requests and outgoing HTTP responses. It can capture request and response properties, headers, and, when explicitly configured, body information. Developers can control the level of detail, configure specific headers, limit body logging, combine request and response information, and apply endpoint-specific rules. 

The most important consideration is responsible configuration. Detailed HTTP logging can be extremely useful when diagnosing an application, but excessive logging can affect performance and may expose sensitive information. Redaction, selective logging, appropriate body-size limits, and environment-specific configurations should therefore be considered when implementing HTTP Logging Middleware in a real ASP.NET Core application.