Changes dependant on targetting 6.0

[MihaZupan]

List of known changes we should do in Yarp once adding a 6.0 target (and/or more convenient after dropping 3.1):

• Use non-validated header enumeration API Proposal: Non-validated HttpHeaders enumeration dotnet/runtime#35126 (comment)
• Call Cancellable/Sync overloads of HttpContent.ReadAsStream* Pass CancellationToken to HttpContent.ReadAsStreamAsync for .Net 5.0 #770
• Doc Kestrel response header encoding dotnet/aspnetcore#33776 here: https://github.com/microsoft/reverse-proxy/blob/16ab855a5be980a0cf5fd21e9a7028190b6e7dda/docs/docfx/articles/http-client-config.md#httpclient
• CancellationTokenSource pooling Pool CancellationTokenSources in 6.0+ #902
• Remove ActivityPropagationHandler in favour of the DistributedContextPropagator that can be customized on a per-handler basis Allow specifying a context propagator on SocketsHttpHandler dotnet/runtime#55556
• Use Random.Shared in RandomFactory
• Update NameResolutionMetrics to include current-dns-lookups Add current-dns-lookups counter to System.Net.NameResolution dotnet/runtime#49146
• Implement the cancellable overload of HttpContent.SerializeToStreamAsync (5.0) (Always wait for the request content to complete #1271)
• Use WaitAsync task timeout extensions instead of TimeoutAfter

Feel free to add anything I may be missing

[Kahbazi]

How about using Random.Shared in RandomFactory?

[Tratcher]

Note adding 6.0 support is independent from dropping 3.1 support. Are there any of these you think are prohibitive to #if light-up on 5.0 or 6.0 while still supporting 3.1?

[MihaZupan]

For #770 we should just wait to drop 3.1. For others it's actually that we need 6.0.

[davidfowl]

Just move the ifdefs to extension methods that noop, it'll keep the code clean. It's the technique we use in Pipelines and Channels in the BCL.

• https://github.com/dotnet/runtime/blob/41af30ca291e0435083c0d4b5d70e2939e0dbc3d/src/libraries/System.IO.Pipelines/src/System/IO/Pipelines/StreamExtensions.netstandard.cs
• https://github.com/dotnet/runtime/blob/41af30ca291e0435083c0d4b5d70e2939e0dbc3d/src/libraries/System.IO.Pipelines/src/System/IO/Pipelines/CancellationTokenExtensions.netstandard.cs

You could do the same with TryReset and assume it always returns false.

[Tratcher]

• Implement the cancellable overload of HttpContent.SerializeToStreamAsync (5.0)
  https://github.com/dotnet/runtime/blob/c14ac488cc5f7d2ad71e7f81d6a05a1da8c76237/src/libraries/System.Net.Http/src/System/Net/Http/HttpContent.cs#L354
  

  reverse-proxy/src/ReverseProxy/Proxy/StreamCopyHttpContent.cs

  Line 119 in d593701

  protected override async Task SerializeToStreamAsync(Stream stream, TransportContext? context)

Fixed by #1271

[Tratcher]

• Doc Kestrel response header encoding dotnet/aspnetcore#33776 here: https://github.com/microsoft/reverse-proxy/blob/16ab855a5be980a0cf5fd21e9a7028190b6e7dda/docs/docfx/articles/http-client-config.md#httpclient

[Kahbazi]

Use LoggerMessageAttribute.

[Kahbazi]

Use PeriodicTimer.

[WeihanLi]

• Use WaitAsync task timeout extensions instead of TimeoutAfter

[MihaZupan]

@Kahbazi where are you suggesting we should use PeriodicTimer?

[Kahbazi]

@Kahbazi where are you suggesting we should use PeriodicTimer?

Here

reverse-proxy/src/ReverseProxy/Utilities/TimerWrapper.cs

Line 14 in db7c3ff

_realTimer = new Timer(callback, state, dueTime, period);

[MihaZupan]

We are only using this within EntityActionScheduler where the API surface is different from what PeriodicTimer offers.

[Kahbazi]

We are only using this within EntityActionScheduler where the API surface is different from what PeriodicTimer offers.

I assumed the overall performance might be better.

[MihaZupan]

Now that we are targeting 6.0 and most items have been completed, I moved the remaining ones into separate issues (#1346 #1347 #770)