Pass CancellationToken to HttpContent.ReadAsStreamAsync for .Net 5.0

[Kahbazi]

A new overload for HttpContent.ReadAsStreamAsync is introduced in .Net 5.0 which gets CancellationToken. Should it be used?

https://github.com/microsoft/reverse-proxy/blob/b734f195b55d0ba623caf88262342d9068402042/src/ReverseProxy/Service/Proxy/HttpProxy.cs#L481
https://github.com/microsoft/reverse-proxy/blob/b734f195b55d0ba623caf88262342d9068402042/src/ReverseProxy/Service/Proxy/HttpProxy.cs#L533

[Tratcher]

@ManickaP the HttpContent on the response always synchronously returns a stream, right? The CT wouldn't be used?

[MihaZupan]

For built-in ones it will, but a custom HttpContent may end up doing async work.

We could also do a type check for SocketsHttpHandler and call the sync API here to save the Task allocation.

[ManickaP]

the HttpContent on the response always synchronously returns a stream, right? The CT wouldn't be used?

Yep, the CT is not used, response content returns stream synchronously:
https://github.com/dotnet/runtime/blob/master/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/HttpConnectionResponseContent.cs#L77-L78

We could also do a type check for SocketsHttpHandler and call the sync API here to save the Task allocation.

👍 Since overriding response content is highly unlikely (returned by the client) we could just call synchronous ReadAsStream in those two places

[karelz]

Triage: Once we drop 3.1 support, we should just do it. #ifdef-ing the code now is not worth the effort.

[samsp-msft]

Should discuss lifetime of 3.1 support now that .NET 6 with LTS is shipped.

[karelz]

Triage: Removing 3.1 support won't likely happen in 1.1 of YARP. It is also major breaking change (technically).