次の方法で共有


HTTP: IHttpClientFactory ログ整数状態コードによって作成された HttpClient インスタンス

HttpClient IHttpClientFactoryによって作成されたインスタンスは、状態コード名ではなく、HTTP 状態コードを整数としてログに記録します。

導入されたバージョン

5.0 Preview 1

以前の動作

ログ記録では、HTTP 状態コードのテキスト記述が使用されます。 次のログ メッセージについて考えてみましょう。

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

新しい動作

ログ記録では、HTTP 状態コードの整数値が使用されます。 次のログ メッセージについて考えてみましょう。

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

変更の理由

このログ記録の元の動作は、常に整数値を使用している ASP.NET Core の他の部分と矛盾しています。 この不整合により、 Elasticsearch などの構造化ログ システムを使用してログを照会するのが困難になります。 詳細については、 dotnet/extensions#1549 を参照してください。

整数値を使用すると、値の範囲に対するクエリが可能になるため、テキストよりも柔軟性が高くなります。

整数状態コードをキャプチャするための別のログ値の追加が検討されました。 残念ながら、これを行うと、ASP.NET Core の残りの部分にもう 1 つの不整合が発生します。 HttpClient ログと HTTP サーバー/ホスティング ログには、既に同じ StatusCode キー名が使用されています。

最適なオプションは、状態コードの整数値を使用するようにログ 記録クエリを更新することです。 このオプションを選択すると、複数の ASP.NET Core バージョン間でクエリの記述が困難になる場合があります。 ただし、この目的で整数を使用すると、ログのクエリを実行する方がはるかに柔軟になります。

古い動作との互換性を強制し、テキスト状態コードを使用する必要がある場合は、 IHttpClientFactory ログを独自のログに置き換えます。

  1. 次のクラスの .NET Core 3.1 バージョンをプロジェクトにコピーします。

  2. Microsoft.Extensions.Http NuGet パッケージ内のパブリック型との競合を避けるために、クラスの名前を変更します。

  3. LoggingHttpMessageHandlerBuilderFilterの組み込みの実装を、プロジェクトの Startup.ConfigureServices メソッド内の独自の実装に置き換えます。 例えば次が挙げられます。

    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>();
    }
    

影響を受ける API

System.Net.Http.HttpClient