azure-encryption-extensions

azure-encryption-extensions copied to clipboard

Using the memory stream download, the file stop downloading at 90%

Using the file download version, the file is downloaded correctly.

Any suggestion?

Is it consistently reproducible, or just a one-time failure? What was the approximate size of the file?

Are you using the source from this repository or the nuget package?

Thanks!

It is reproducible as continuously failure. The files are all small 100/200kbs

I am using the nuget package in combination with this example http://arcware.net/upload-and-download-files-with-web-api-and-azure-blob-storage/ but of course using your upload and download.

Sounds like I found the problem, when the download is finished the BlobLenght property is not the same of the stream lenght and it make the problem with the browser. If I make the BlobLengh the same of the Stream lenght, then it work.

  var download = new GenericModels.BlobDownloadModel
            {
                BlobStream = ms,
                BlobFileName = fileName,
                BlobLength = ms.Length,
                BlobContentType = blob.Properties.ContentType
            };

I want to follow up on this as I think other people may have a similar problem. This scenario where you want to let users download the files directly is challenging because currently you have no way of knowing the actual file length without decrypting the entire thing. The encrypted blob length will not be the same as the decrypted data length ever.

In your case it seems you downloaded the blob into a memory stream, so you had it all in memory and could provide the length. This works for some scenarios, but if you want to work with very large files you would ideally never buffer them locally and instead stream the data out at the same time you downloaded/decrypted it from blob store. (So you'd pass the stream from us directly to the response stream).

Certainly removing the length header entirely is an option, but it isn't ideal.

If I had thought of this at design time I would have packed the original file size into the front of the blob so we could provide an accurate length for the stream, but changing this now would break compatibility. We can investigate adding it as a non-default option for a future release, and in the meantime you can find an alternate way to store your original file length (in the blob filename for example).