[Core] Don't throw from Response.Content if memory stream is private

[ellismg]

Relax our constraint that the underlying buffer of the MemoryStream
backing a buffered response be publicly visible. There are cases today
where RequestBodyPolicy will not allocate a new MemoryStream. One
example is if the response stream is already seekable (as is the case
in our PlaybackTransport) nd we've observed that there are likely
cases where HttpClient itself may use a MemoryStream as the response
stream without allowing the underling buffer to be exposed.

In cases where we can not extract the underlying body, just make a
copy of it. Since we know the underlying stream is a memory stream, we
don't need to worry about hidden IO.

Fixes #21048

[ellismg]

I was never able to reproduce this issue when running against a live service, but we were able to hit it in playback. If we are worried about the case where the response content is a seekable stream, but not an exposable memory stream, (and so the early out we were doing was saving us a copy compared to what we would do with this change) we could try to do something more targeted in Response.Content where if the response is a MemoryStream but the buffer can't be expose we just use CopyTo to copy it to a new memory buffer, exploiting the fact that CopyTo on a memory stream won't do I/O.

But fixing things in the policy such that when buffering is requested, you always end up with an exposable memory stream as your stream felt like the right place to do this.

[pakrym]

I wonder if the fix should be here or in the .Content implementation itself. Both would result in a copy but if we do it in the property it's pay-for-play.

[ellismg]

Thought about that as well - the one concern I had was if we would replace the ContentStream on the Response as part of doing this (so future calls to .Content would not need to copy) and if doing so would be weird because of things like:

Stream s1 = response.ContentStream;
Console.WriteLine(response.Content);
Stream s2 = response.ContentStream;

Object.ReferenceEquals(s1, s2) // could return false?!

Do you think this would be surprising in practice?

[pakrym]

It's not exactly what I've meant.

I was thinking of replacing

azure-sdk-for-net/sdk/core/Azure.Core/src/Response.cs

Line 75 in 0cecb0e

throw new InvalidOperationException($"The {nameof(ContentStream)}'s internal buffer cannot be accessed.");

with

return memoryContent.ToArray();

[ellismg]

Sounds reasonable to me, I suppose if we find that folks are calling .Content a bunch (and that's commonly leading to a bunch of copies) we can either figure a way to cache the value in Response (and eat the size increase) or explore something like swapping out the stream with a memory stream that exposes it's underlying buffer.

[ellismg]

@pakrym please take another look.

[JoshLove-msft]

Maybe assert that the arrays have the same sequence?

[JoshLove-msft]

nit: The PR description is no longer up to date.

[pakrym]

Can you please add a changelog entry?