Failed when MemoryStream is wrapped inside a BufferedReadStream

[kulkarnimeghak]

Description

Creating a file with seeking support, combined with BufferedReaderStream failing with error message "The value must be greater than zero. Parameter name: count"

To Reproduce

Steps to reproduce the behavior:

1. Using ASP.NET Core '2.1'
2. Add below middleware

app.Use (async (context, next) =>
             {
                // Create a copy of current request stream and save it as MemoryStream,
                // Other stream classes can be used as well, as long as they support seeking.
                // In other words, CanSeek must return true.
                var stream = new MemoryStream ();
                context.Request.Body.CopyTo (stream);
                stream.Position = 0; // Rewinding stream

               // Wrap copied stream with BufferedReadStream
               // and set as new body stream.
               // This step is important for reproduction.
               context.Request.Body = new BufferedReadStream (stream, 81920);
               context.Response.RegisterForDispose (context.Request.Body);
               await next.Invoke ();
             });

3. Sends the HTTP request to upload file to azure blob storage (I'm using Azure storage emulator)

POST http://localhost:5000/api/files/upload HTTP/1.1
Content-Type: multipart/form-data; boundary=-------------------------acebdf13572468
User-Agent: Fiddler
Host: localhost:5000
Content-Length: 224

---------------------------acebdf13572468
Content-Disposition: form-data; name="fieldNameHere"; filename="TestfileWithdata.txt"
Content-Type: text/plain

test file with data
---------------------------acebdf13572468--

4. See error
   Status code :400
   error message: The value must be greater than zero.Parameter name: count
   stack trace: 

at Microsoft.AspNetCore.WebUtilities.BufferedReadStream.ValidateBuffer(Byte[] buffer, Int32 offset, Int32 count)
   at Microsoft.AspNetCore.WebUtilities.BufferedReadStream.ReadAsync(Byte[] buffer, Int32 offset, Int32 count, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Http.Internal.ReferenceReadStream.ReadAsync(Byte[] buffer, Int32 offset, Int32 count, CancellationToken cancellationToken)
   at Microsoft.WindowsAzure.Storage.Core.Util.StreamExtensions.WriteToAsync[T](Stream stream, Stream toStream, IBufferManager bufferManager, Nullable`1 copyLength, Nullable`1 maxLength, Boolean calculateMd5, ExecutionState`1 executionState, StreamDescriptor streamCopyState, CancellationToken token) in C:\Program Files (x86)\Jenkins\workspace\release_dotnet_master\Lib\Common\Core\Util\StreamExtensions.cs:line 301
   at Microsoft.WindowsAzure.Storage.Blob.CloudBlockBlob.UploadFromStreamAsyncHelper(Stream source, Nullable`1 length, AccessCondition accessCondition, BlobRequestOptions options, OperationContext operationContext, IProgress`1 progressHandler, CancellationToken cancellationToken) in C:\Program Files (x86)\Jenkins\workspace\release_dotnet_master\Lib\WindowsRuntime\Blob\CloudBlockBlob.cs:line 352
   at Microsoft.WindowsAzure.Storage.Blob.CloudBlockBlob.UploadFromStreamAsyncHelper(Stream source, Nullable`1 length, AccessCondition accessCondition, BlobRequestOptions options, OperationContext operationContext, CancellationToken cancellationToken) in C:\Program Files (x86)\Jenkins\workspace\release_dotnet_master\Lib\WindowsRuntime\Blob\CloudBlockBlob.cs:line 290
   at SampleMSWrapBRS.Helpers.StorageHelper.UploadFileToStorage(Stream fileStream, String fileName, AzureStorageConfig storageConfig) in D:\Learning\2019Q1\MSWrapBRS\WebApplication\SampleMSWrapBRS\StorageHelper.cs:line 31
   at SampleMSWrapBRS.Controllers.FilesController.Upload(ICollection`1 files) in D:\Learning\2019Q1\MSWrapBRS\WebApplication\SampleMSWrapBRS\Controllers\FilesController.cs:line 43

Expected behavior

Should allow uploading file to Azure blob storage.

[Tratcher]

Please show the code where you're consuming the buffered stream (calling storage SDK).

I saw a similar issue over here:
#9499 (comment)

BufferedReaderStream reports Length as the total length buffered so far, starting with 0. It also reports CanSeek = true, because it can seek backwards in the buffer. Some callers take Length as the total length rather than the current length. We should check what storage does.

While the minimal repro is appreciated, can you also summarize how you encountered this situation in a real app? E.g. what combination of middleware lead to this type of request body nesting?

[kulkarnimeghak]

Here is code from sample application where I'm calling storage SDK after opening request stream for reading the uploaded file.

 public static async Task<bool> UploadFileToStorage (Stream fileStream, string fileName, AzureStorageConfig storageConfig)
            {
            var storageAccount = CloudStorageAccount.DevelopmentStorageAccount;
            var blobClient = storageAccount.CreateCloudBlobClient ();
            var container = blobClient.GetContainerReference (storageConfig.FileContainer);
            if (await container.CreateIfNotExistsAsync ())
                {
                await container.SetPermissionsAsync (new BlobContainerPermissions { PublicAccess = BlobContainerPublicAccessType.Blob });
                }
            var blockBlob = container.GetBlockBlobReference (fileName);

            // Upload the file
            await blockBlob.UploadFromStreamAsync (fileStream);
            return await Task.FromResult (true);
            }

We came across this in implementation of batch request and content compression, as with these we use MemoryStream for batch subrequest and for decompressed content.

[Tratcher]

We came across this in implementation of batch request and content compression, as with these we use MemoryStream for batch subrequest and for decompressed content.

How does BufferedReadStream fit into that?

For now I suggest you try wrapping the stream with a pass through stream that suppresses CanSeek and Length.

[analogrelay]

Closing this as we haven't heard from you and generally close issues with no response after ~7 days. Please feel free to comment if you're able to get the information we're looking for and we can reopen the issue to investigate further!