Missing overrides in LoggingHttpMessageHandler and LoggingScopeHttpMessageHandler

[mphelt]

Background and motivation

Both LoggingHttpMessageHandler and LoggingScopeHttpMessageHandler have implementations of:
protected async override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request!!, CancellationToken cancellationToken)
but they are missing implementations of:
protected internal override HttpResponseMessage Send(HttpRequestMessage request, CancellationToken cancellationToken)
It would be great to see these implementations introduced, as otherwise custom implementation of:

• IHttpMessageHandlerBuilderFilter,
• HttpHeadersLogValue,
• LoggingHttpMessageHandler
• LoggingScopeHttpMessageHandler

is needed.
I know that synchronous usage is not expected most of the times, but we've spent quite some time figuring out why we can't turn on those logs in our legacy app migrated to .NET 6 when we tried to figure out how it works.

Risks

No response

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

Issue Details

---

Background and motivation

Both LoggingHttpMessageHandler and LoggingScopeHttpMessageHandler have implementations of:
protected async override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request!!, CancellationToken cancellationToken)
but they are missing implementations of:
protected internal override HttpResponseMessage Send(HttpRequestMessage request, CancellationToken cancellationToken)
It would be great to see these implementations introduced, as otherwise custom implementation of:

• IHttpMessageHandlerBuilderFilter,
• HttpHeadersLogValue,
• LoggingHttpMessageHandler
• LoggingScopeHttpMessageHandler

is needed.
I know that synchronous usage is not expected most of the times, but we've spent quite some time figuring out why we can't turn on those logs in our legacy app migrated to .NET 6 when we tried to figure out how it works.

Risks

No response

Author:	mphelt
Assignees:	-
Labels:	untriaged, area-Extensions-HttpClientFactory
Milestone:	-

[MihaZupan]

Providing implementations for sync paths makes sense. In this case, it doesn't only affect performance, but also the functionality of such handlers.
@mphelt would you be interested in contributing the change?

[mphelt]

@MihaZupan Sure, please find #85143.
I didn't create copy of all tests that use SendAsync, but only the basic ones to check if it works - I hope that's enough.