Geeks With Blogs

News This is the *old* blog. The new one is at blog.sixeyed.com
Elton Stoneman
This is the *old* blog. The new one is at blog.sixeyed.com

In the early days of Azure blob storage, the response headers for HTTP GET requests were not quite right. The ETag header wasn't escaped with double-quotes, which is not correct, and HTTP clients may not cache correctly without them; and the Accept-Ranges header wasn't returned, which doesn't play nicely with clients wanting to support interrupted & resumed downloads.

That was fixed with an update to the storage service that came way back in 2011, but Azure has a very cautious approach to widespread changes like this and you have to opt-in to get the latest features. That's still the case, so unless you explicitly set it up, you won't get those headers for storage accounts and containers you create today.

Here's the default header response for a brand-new container in a new storage account:

curl -I https://xyz.blob.core.windows.net/my-file.zip

HTTP/1.1 200 OK 
Content-Length: 97071076 
Content-Type: application/octet-stream 
Content-MD5: JHZsasfd1G2AY14g58iCU6Q== 
Last-Modified: Mon, 01 Sep 2014 09:37:09 GMT 
ETag: 0x8D193DF6FABC5262 
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0 
x-ms-request-id: 4c658e1b-0001-0012-0175-ab43d5000000 
x-ms-version: 2009-09-19 
x-ms-lease-status: unlocked 
x-ms-blob-type: BlockBlob 
Date: Fri, 26 Sep 2014 14:29:15 GMT

Note the ETag is non-compliant, there's no Accept-Ranges, and the x-ms-version header which tells you the version of storage service that supplied the response, is stuck back in 2009.

You can explicitly request a different version of the storage service by supplying that header in the request. Make the same request and specify an Azure service version later than 2011 with the x-ms-version header (2014-02-14 here):

curl -I -H x-ms-version:2014-02-14  https://xyz.blob.core.windows.net/my-file.zip

HTTP/1.1 200 OK 
Content-Length: 97071076 
Content-Type: application/octet-stream 
Content-MD5: JHZsasfd1G2AY14g58iCU6Q== 
Last-Modified: Mon, 01 Sep 2014 09:37:09 GMT 
Accept-Ranges: bytes 
ETag: "0x8D193DF6FABC5262" 
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0 
x-ms-request-id: 4ab79588-0001-0015-36f2-199808000000 
x-ms-version: 2014-02-14 
x-ms-lease-status: unlocked 
x-ms-lease-state: available 
x-ms-blob-type: BlockBlob 
Date: Mon, 29 Sep 2014 07:15:23 GMT

And you get the improved headers, with Accept-Ranges and a compliant ETag.

You could argue that new storage accounts should default to using the latest API version, but that would be a breaking change for any systems expecting the old headers - if you swapped an old storage account for an existing service to a new one, you'd expect it to behave in the same way.

You can specify which API version the services should default to at the storage account level, but you can't do it through the management portal - you can have fun generating a signature for the Blob Service REST API, or you can do it in a few lines of code with the WindowsAzure.Storage NuGet package:

	var connectionString = "DefaultEndpointsProtocol=https;AccountName={accountName};AccountKey={accountKey}";
	var storageAccount = CloudStorageAccount.Parse(connectionString);
	var blobClient = storageAccount.CreateCloudBlobClient();
	var props = blobClient.GetServiceProperties();
	props.DefaultServiceVersion = "2014-02-14";
	blobClient.SetServiceProperties(props);
Now any requests for blobs which don't specify an explicit service version will default to 2014-02-14 and get the enhanced response headers. Posted on Thursday, October 9, 2014 7:43 AM Azure | Back to top


Comments on this post: Configure Azure storage to return proper response headers for blob GETs

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Elton Stoneman | Powered by: GeeksWithBlogs.net