Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HttpClient instances created by IHttpClientFactory will now log HTTP status codes as integers instead of with status code names #396

rynowak opened this issue Nov 26, 2019 · 0 comments


Copy link

@rynowak rynowak commented Nov 26, 2019

HttpClient logging

HttpClient instances created by IHttpClientFactory will now log HTTP status codes as integers instead of with status code names.

Version introduced

5.0 preview 1

Old behavior

Logging would use the textual descriptions of HTTP status codes:

Received HTTP response after 56.0044ms - OK
End processing HTTP request after 70.0862ms - OK

New behavior

Logging will use the integer values of HTTP status codes:

Received HTTP response after 56.0044ms - 200
End processing HTTP request after 70.0862ms - 200

Reason for change

The original behavior of this logging is inconsistent with other parts of ASP.NET Core that have always used integer values. This inconsistency makes logs hard to query via structured logging systems such as ElasticSearch. See aspnet/Extensions#1549

Using integer values is ultimately more flexible than text because it allows queries on ranges of values.

We considered adding an additional log value to capture the integer status code, but that would introduce another inconsistency with the rest of ASP.NET Core. HttpClient logging and HTTP server/hosting logging use the same key name (StatusCode) already.

Recommended action

The best option is update logging queries to use the integer values of status codes. While this may cause some difficulty writing queries across multiple ASP.NET Core versions right now, we believe that using integers for this purpose is much more flexible for querying logs.

If for some reason you need to force compatibility with the old behavior, and use textual status codes, you can do this by replacing IHttpClientFactory's logging with your own.

  1. Copy the 3.1 versions of LoggingHttpMessageHandlerBuilderFilter LoggingHttpMessageHandler LoggingScopeHttpMessageHandler and HttpHeadersLogValue into your project.

  2. Rename these types to avoid conflicts with public types in the Microsoft.Extensions.Http package

  3. Replace the built-in implementation of LoggingHttpMessageHandlerBuilderFilter with your own inside Startup.Configure(IServiceProvider services)

        public void ConfigureServices(IServiceCollection services)
            // other service registrations go first

            // place after all AddHttpClient registrations
            var descriptors = services.Where(s => s.ServiceType == typeof(IHttpMessageHandlerBuilderFilter));
            foreach (var descriptor in descriptors)

            services.AddSingleton<IHttpMessageHandlerBuilderFilter, MyLoggingHttpMessageHandlerBuilderFilter>();



Affected APIs

Not detectable via API analysis

Issue metadata

  • Issue type: breaking-change
@rynowak rynowak added this to the 5.0 milestone Nov 26, 2019
@aspnet aspnet locked as resolved and limited conversation to collaborators Nov 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
1 participant
You can’t perform that action at this time.