azure-sdk-for-net: 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

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 15 (9 by maintainers)

Most upvoted comments

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.

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.
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.
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.

tg-msft on Oct 14, 2020

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.

amnguye on Oct 1, 2020

@tg-msft could you jump in with why we allow users to specify values that are not valid to the service. I believe there’s a SDK guideline (something like that) with allowing the service to handle error messages.

With creating more user friendly error messages, we actually have an issue already open for that. See https://github.com/Azure/azure-sdk-for-net/issues/14469

amnguye on Oct 5, 2020

The response has a payload that contain information about which header is invalid. We should either expose it or add client side validation.

kasobol-msft on Oct 5, 2020

So why does the AcquireAsync allow me to specify a value < 15 seconds?! I still think this is a bug. I’d say:

the AcquireAsync should parse these inputs
when an invalid time is specified an error message along the lines of “x is an invalid time period” should be returned, not the very cryptic “The value for one of the HTTP headers is not in the correct format.”. I mean why is this even talking about headers. I’m not using the REST api directly. I’m using a wrapper class.

Yes @seanmcc-msft please could you re-open this ticket

sonic1981 on Oct 2, 2020

I did actually get something working https://stackoverflow.com/a/64136116/542251

But the above looks to me like it should work. So why doesn’t it?

I’d suggest at the very least that the error message is confusing/vague.

sonic1981 on Sep 30, 2020