EnableRewind for HttpResponse similar to HttpRequest

[jimmy3912msncom]

1. Description of the problem: EnableRewind for HttpResponse similar to HttpRequest
   This is more of a feature request than anything. I have need to log the response body but this requires the need for a rewindable response stream. HttpRequest has the extension method defined: BufferingHelper.EnableRewind for HttpRequest. The ask is for a similar extension method for HttpResponse so we don't have to swap out the streams manually ourselves.
2. The version of Microsoft.AspNetCore.All: 2.1.2
3. The output of dotnet --info
   .NET Core SDK (reflecting any global.json):
   Version: 2.1.302
   Commit: 9048955601

Runtime Environment:
OS Name: Windows
OS Version: 10.0.17134
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\2.1.302\

Host (useful for support):
Version: 2.1.2
Commit: 811c3ce6c0

.NET Core SDKs installed:
2.0.2 [C:\Program Files\dotnet\sdk]
2.0.3 [C:\Program Files\dotnet\sdk]
2.1.4 [C:\Program Files\dotnet\sdk]
2.1.104 [C:\Program Files\dotnet\sdk]
2.1.201 [C:\Program Files\dotnet\sdk]
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.302 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download

[Tratcher]

There's a sample for response buffering here:
https://github.com/aspnet/BasicMiddleware/blob/15d5545d59c2f966ed0c730c565c1b9105b258de/src/Microsoft.AspNetCore.Buffering/ResponseBufferingMiddleware.cs

That said, you don't want to do this for arbitrary responses, it can consume a lot of memory. There can also be a lot of sensitive data in response bodies that you should think twice about before writing to logs.

[jimmy3912msncom]

@Tratcher Thanks. I know of the samples. I've seen multiple online.

I understand that it shouldn't be done for arbitrary responses. My intention was to turn it on for verbose logging flows when we are trying to debug some issues. The point of the sensitive data is the same whether for request bodies or response bodies but for some reason it is only supported for requests. The ask here is to support a mirrored version for responses too.

[Tratcher]

I was referring to logging sensitive data, not buffering it.

[Tratcher]

Response buffering can never be as simple as EnableRewind for the request. On the request you only need to replace the stream. On the response side you have to both replace the stream and add something like a middleware to eventually flush the data.

[jimmy3912msncom]

@Tratcher Yup. I knew you were referring to logging sensitive data and I meant the same thing. I wasn't talking about buffering.

So the difference you are saying is the step of flushing the data? Is it just the implementation that is causing the issue? Does the default Response stream implementation also have the need for explicit flushing? If it does couldn't this fall into the same pattern as they are ultimately all streams?

[Tratcher]

The original response body stream is provided by the server, is unbuffered, and the server reacts immediately to each write. The server doesn't track replacements of response.Body, it's the responsibility of the component that did the replacement to eventually copy the data back to the original server response body stream.

[jimmy3912msncom]

@Tratcher Thanks for the explanation.

[analogrelay]

Due to the need for app-specific logic @Tratcher mentioned, this isn't something we plan to implement in upcoming versions.

[Tratcher]

@pranavkm can you cross link your work here?