Share via


HTTP: Instâncias de HttpClient criadas por códigos de status em inteiro do log IHttpClientFactory

Instâncias HttpClient criadas por códigos de status HTTP do log IHttpClientFactory como inteiros em vez de serem criadas pelos nomes do código de status.

Versão introduzida

5.0 versão prévia 1

Comportamento antigo

O registro em log usa as descrições textuais dos códigos de status HTTP. Considere as seguintes mensagens de log:

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

Novo comportamento

O registro em log usa os valores em inteiros dos códigos de status HTTP. Considere as seguintes mensagens de log:

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

Motivo da alteração

O comportamento original desse registro em log é inconsistente com outras partes do ASP.NET Core que sempre usaram valores em inteiros. A inconsistência dificulta a consulta de logs por meio de sistemas de log estruturados, como o Elasticsearch. Para obter mais contexto, consulte dotnet/extensions#1549.

O uso de valores em inteiros é mais flexível do que texto, pois permite consultas em intervalos de valores.

Foi considerada a adição de outro valor de log para capturar o código de status em inteiro. Infelizmente, fazer isso introduziria outra inconsistência com o resto do ASP.NET Core. O registro em log do HttpClient e o registro em log do servidor/hospedagem HTTP já usam o mesmo nome de chave StatusCode.

A melhor opção é atualizar as consultas de log para que utilizem os valores em inteiro dos códigos de status. Essa opção pode causar alguma dificuldade na gravação de consultas em várias versões do ASP.NET Core. No entanto, o uso de inteiros para essa finalidade é muito mais flexível para consultar logs.

Se você precisar forçar a compatibilidade com o comportamento antigo e usar códigos de status textuais, substitua o registro em log IHttpClientFactory pelo seu próprio:

  1. Copie as versões do .NET Core 3.1 das seguintes classes em seu projeto:

  2. Renomeie as classes para evitar conflitos com tipos públicos no pacote NuGet Microsoft.Extensions.Http.

  3. Substitua a implementação interna de LoggingHttpMessageHandlerBuilderFilter pela sua própria implementação no método Startup.ConfigureServices do projeto. Por exemplo:

    public void ConfigureServices(IServiceCollection services)
    {
        // Other service registrations go first. Code omitted for brevity.
    
        // Place the following after all AddHttpClient registrations.
        services.RemoveAll<IHttpMessageHandlerBuilderFilter>();
    
        services.AddSingleton<IHttpMessageHandlerBuilderFilter,
                              MyLoggingHttpMessageHandlerBuilderFilter>();
    }
    

APIs afetadas

System.Net.Http.HttpClient