When doing a multipart upload the underlying AesGcmEncryptStream for the V2 client. This allows the encryption state to persist across part uploads. The SDK when seeing the the InputStream was created in behalf of the user because they set the FilePath property would close the stream after the request was complete. This had the side affect of closing the shared AesGcmEncryptStream causing the second part upload to fail to upload.
To accommodate the SDK closing the stream I added a DisableDispose property on AesGcmEncryptStream that if set to true would cause the dispose/close on the AesGcmEncryptStream to be a noop. The encryption client would set DisableDispose to true for all parts except the last part.
By not having the SDK close the stream that also meant if an exception occurred anything besides the last part the stream would not be closed. In the V2 encryption pipeline handler I added the HandleException to be called whenever there were request pipeline exception and force the AesGcmEncryptStream stream to be closed even if the DisableDispose property was true.
Unrelated to the issue I also removed the references to a constant from the obsolete S3 encryption client in the AWSSDK.S3 package. Since we are removing that client in V4 seemed good to remove that reference while I was here.
Change the existing tests to use large files forcing multipart uploads in the TransferUtility directory upload. I also forced exceptions to confirm the HandleException in the pipeline handler was closing the stream.
Description
When doing a multipart upload the underlying
AesGcmEncryptStreamfor the V2 client. This allows the encryption state to persist across part uploads. The SDK when seeing the theInputStreamwas created in behalf of the user because they set theFilePathproperty would close the stream after the request was complete. This had the side affect of closing the sharedAesGcmEncryptStreamcausing the second part upload to fail to upload.To accommodate the SDK closing the stream I added a
DisableDisposeproperty onAesGcmEncryptStreamthat if set to true would cause the dispose/close on theAesGcmEncryptStreamto be a noop. The encryption client would setDisableDisposeto true for all parts except the last part.By not having the SDK close the stream that also meant if an exception occurred anything besides the last part the stream would not be closed. In the V2 encryption pipeline handler I added the
HandleExceptionto be called whenever there were request pipeline exception and force theAesGcmEncryptStreamstream to be closed even if theDisableDisposeproperty was true.Unrelated to the issue I also removed the references to a constant from the obsolete S3 encryption client in the AWSSDK.S3 package. Since we are removing that client in V4 seemed good to remove that reference while I was here.
Motivation and Context
https://github.com/aws/amazon-s3-encryption-client-dotnet/issues/54
Testing
Change the existing tests to use large files forcing multipart uploads in the TransferUtility directory upload. I also forced exceptions to confirm the
HandleExceptionin the pipeline handler was closing the stream.