Do HTTP RANGE headers work with Azure Blob Storage Shared Access Signatures?

I reached out to some members of the product team and was given the following...

The 200 vs 206 is due to the presents of the "-I" flag in the curl command. This results in a HEAD request instead of a GET which is essentially as "get blob properties" call instead of a "get blob" which will cause the range header to be ignored. Also be sure to specify the version headers as "x-ms-version:2011-08-18" or later since the "startByte-" range format was only supported on that version of later.

For more information on range headers, see: http://msdn.microsoft.com/en-us/library/windowsazure/ee691967.aspx


For those who are struggling with the Azure Service API and the tricky Authorization, I recommend the this very simple C# snippet that does exactly the same in a very simpler way (at least for me).

        var credentials = new Microsoft.WindowsAzure.Storage.Auth.StorageCredentials("storagename", "storagekey");
        var account = new Microsoft.WindowsAzure.Storage.CloudStorageAccount(credentials, true);
        var client = account.CreateCloudBlobClient();
        var properties = client.GetServiceProperties();
        properties.DefaultServiceVersion = "2013-08-15";
        client.SetServiceProperties(properties);

You'll need to add a nuget package WindowsAzure.Storage v9.3.3 (obsolete, but still works)


We got this straightened out.

As @BrentDaCodeMonkey mentioned, Azure returns the expected 206 response if you're using API version 2011-01-18 or better, but in our case we don't originate the request so we can't specify this using the request header.

However, some Microsoft friends tipped us of to the fact that you can set the API version globally for a storage account, but you need to use the REST API to do so (it's not something you can do in the management UI). This post explains how:

http://msdn.microsoft.com/en-us/library/windowsazure/hh452235.aspx

After setting the DefaultServiceVersion to 2011-01-18, we're now getting back the expected 206 status for RANGE requests.