BlobLeaseClient.GetBlobClient returns "The value for one of the HTTP headers is not in the correct format" exception

Describe the bug When trying to aquire a lease on a blob I get the an exception.

Expected behavior I should be able to acquire a lease on this blob.

Actual behavior (include Exception or Stack Trace)

The value for one of the HTTP headers is not in the correct format.
RequestId:<guid>
Time:2020-09-30T10:28:47.8781946Z
Status: 400 (The value for one of the HTTP headers is not in the correct format.)
ErrorCode: InvalidHeaderValue

Headers:
Server: Windows-Azure-Blob/1.0,Microsoft-HTTPAPI/2.0
x-ms-request-id: <guid>
x-ms-client-request-id: <guid>
x-ms-version: 2019-12-12
x-ms-error-code: InvalidHeaderValue
Date: Wed, 30 Sep 2020 10:28:47 GMT
Content-Length: 328
Content-Type: application/xml

To Reproduce

BlockBlobClient blockBlobClient = new BlockBlobClient(
                "connectionstring", 
                "containername", 
                "blob");

BlobLeaseClient blc = blockBlobClient.GetBlobLeaseClient();

//exception here
BlobLease bl = await blc.AcquireAsync(new TimeSpan(0, 0, 10));

Environment:

• Azure.Storage.Blobs, Version=12.6.0.0

[tg-msft]

Client-side validation can result in really painful forward compatibility problems.

To better illustrate, let’s pretend we added client-side validation for an operation like Set Blob Tags. There’s a maximum of 10 tags so why not enforce that before we send an expensive request across the network? It seems safe.

1. Imagine a customer writing an application using 2019-12-12 that wants to update a tag. They first get the current tags, increment one of the values, and then set the tags again to update. They test, see it works fine, and deploy their application.
2. Now time travel several years into the future. It turns out blob tags have become wildly popular and customers are demanding more and more tags. Imaginary future service version 2022-02-22 increases the limit to a hypothetical 32 tags.
3. What happens when a different part of that customer’s distributed system starts adding more tags using a client library compiled against 2022-02-22 where 10 is no longer the limit?
   • The code in Step 1 will get the tags using 2019-12-12
   • Even though the limit for 2019-12-12 was 10 tags, if the resource happens to have 16 tags after manipulation by 2022-02-22 the service will still return them all. (It’s kind of tricky here, but you’d effectively be lying about the state of the resource if you only returned 10… and which 10? the first 10? plus it’d be so confusing if someone deleted one but we still returned 10? etc. The service really has no choice but to return them all and let the client deal with it.)
   • The code in Step 1 will happily download and mutate with 16 tags. But if we’re doing client-side validation, updating will now throw because it’s suddenly getting 16 tags.
   • A customer app that worked fine in production for years is now broken.

It’s harder to imagine something like this happening with blob leases, but I could see someone getting the current lease duration via GetProperties and calling LeaseClient.Break with it (i.e., I’ll let you finish one lease, but not renew it).

If we can’t make the error messages better with #14469, then the most we should do is post facto client-side validation where we catch the error, determine it’s because the lease was out of range, and then wrap it in an exception that’s more helpful to customers.

[amnguye]

Hi,

“A non-infinite lease can be between 15 and 60 seconds”. https://docs.microsoft.com/en-us/rest/api/storageservices/lease-blob (see x-ms-lease-duration)

That’s why the stackoverflow link you used worked cause it was 30 seconds while the snippet you provided was 10 seconds. So the error code you got back from the service “InvalidHeaderValue” is correct.