Missing overrides in LoggingHttpMessageHandler and LoggingScopeHttpMessageHandler

[mphelt]

add missing overrides in LoggingHttpMessageHandler and LoggingScopeHttpMessageHandler

Fixes #85104

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

add missing overrides in LoggingHttpMessageHandler and LoggingScopeHttpMessageHandler (#85104)

Author:	mphelt
Assignees:	-
Labels:	area-Extensions-HttpClientFactory, community-contribution
Milestone:	-

[mphelt]

@dotnet-policy-service agree

[CarnaViire]

@mphelt thanks for your contribution!
You need to surround your overrides in #if NET5_0_OR_GREATER because synchronous Send was only added in .NET 5: https://learn.microsoft.com/en-us/dotnet/api/system.net.http.httpmessagehandler.send
And test should have a filter as well: [ConditionalFact(typeof(PlatformDetection), nameof(PlatformDetection.IsNetCore))]

[mphelt]

@CarnaViire

You need to surround your overrides in #if NET5_0_OR_GREATER

I've added them, but I didn't thought of it initially, as none of the base classes has those conditions - how are they different?

@Wraith2
I've fixed those typos in both my copy of the remarks as well as the source one.

[MihaZupan]

Can we deduplicate this logic between Send and SendAsync (same for LoggingScopeHttpMessageHandler)?

E.g. by extracting it to a helper method

private async Task<HttpResponseMessage> SendAsyncCore(HttpRequestMessage request, bool async, CancellationToken cancellationToken)

[MihaZupan]

Just a few comments regarding the code style used in this repo, otherwise looks good, thanks.

Unfortunately I had to add #if NET5_0_OR_GREATER directives inside useAsync ? ... : ... - is there a cleaner way to do that?

I think it's okay as-is.

[CarnaViire]

I've added them, but I didn't thought of it initially, as none of the base classes has those conditions - how are they different?

It's because previously only .NET Standard 2.0 API surface was used, which includes only async send: https://learn.microsoft.com/en-us/dotnet/api/system.net.http.delegatinghandler.sendasync?view=netstandard-2.0 -- because Microsoft.Extensions.Http is compiled for .NET Standard 2.0.
But we missed the fact that when it's used in .NET 5+ apps, the sync API can be used, but it won't be overridden.

Handlers that this PR is changing are not sealed, should I make those helper methods protected virtual?

This would be adding the helper method to the public surface, which should go through API review process: https://github.com/dotnet/runtime/blob/main/docs/project/api-review-process.md
In general, I don't think it would bring too much value, as it's more of an implementation detail. Users can still derive from and substitute the logging handlers -- they would just need to override both of the Sends, which is true for deriving from DelegatingHandler as well.
As for configuring logging, there's a separate umbrella issue for that: #77312

[mphelt]

@CarnaViire, thank you for explanation. Is there any way to re-run those failing checks? They seem to have failed for reasons not connected to this particular PR.

[CarnaViire]

@mphelt I believe the failures were fixed in #85304, could you please update to the latest main? Thanks!

[CarnaViire]

LGTM, thanks!

[CarnaViire]

Test failure is unrelated #85772