[BUG] BlobClient.Exists() fails if a blob was uploaded with a customer-provided encryption key

[bkromhout]

Describe the bug
We have blobs that are uploaded with a CustomerProvidedKey (the REST equivalent would be uploading with the x-ms-encryption-key header).

At some later time, we want to check whether one of these blobs exists using the BlobClient.Exists() method. Importantly, the BlobClient instance used to call Exists() is NOT configured with a CustomerProvidedKey.

Expected behavior
Regardless of whether the BlobClient knows a blob's CustomerProvidedKey, the Exists() method should return true if the blob exists. (This is possible, see Further Discussion below.)

Actual behavior
When a BlobClient with no CustomerProvidedKey is used to call Exists() on a blob which was uploaded previously with a CustomerProvidedKey, it gets a 409 error response because the Azure Blob API expects the same encryption key to be passed.

The message returned is "The blob is encrypted with customer specified encryption, but it was not provided in the request", and the x-ms-error-code response header is set to "BlobUsesCustomerSpecifiedEncryption".

Further Discussion
I'm not disputing how the REST API works here; the fact that it's returning this error response makes perfect sense to me. The issue I have is with the SDK's handling of it: I'm just calling BlobClient.Exists(), and this particular error response from the REST API is proof positive that the blob does indeed exist...so my expectation is that the SDK would eat this particular error response and just return true, not error out.

To Reproduce

1. Upload a blob using a CustomerProvidedKey.
2. Using a new BlobClient instance pointed at said blob (which does not have a CustomerProvidedKey configured), call Exists()

Environment:

• Name and version of the Library package used: Azure.Storage.Blobs 12.8.1

[amnguye]

That's valid, that message does infer that the blob exists, we were just unable to decrypt it without the key because a GetProperties call as done to check if the blob exists.

I will mark this as a bug and we will address it accordingly across services that support customer provided encryption keys.