Do RANGE HTTP Headers Work with Azure Blob Shared Signature?

Question

I use Azure Blob storage to store media files and provide access to these files using shared signatures; everything works well in this regard.

However, I have a client application that should “resume” access to these files and does this using the HTTP RANGE header. When he makes such a request, he is unhappy with the result that he returns from Azure.

I'm not sure how to view the details on the Azure side to check if the request failed, or simply returned what the client did not expect, and I do not have debug visibility in the client.

Here's what the header of the incoming range looks like:

RANGE: bytes=4258672- 

From the Azure documentation I read, it seems to support RANGE headers, however, I wonder if there is a conflict using RANGE and sharing signatures together?

Update: It appears that Azure may return an invalid status code for RANGE requests, which causes my client applications to reject the response. The documentation says that Azure will respond with an HTTP status code of 206 when responding to a RANGE request, however, when I issue a RANGE request as follows:

 curl -I -H "User-Agent: Bonos" -r 500- "https://murfie.blob.core.windows.net/168464/1.mp3?st=2013-07-03T16%3A34%3A32.4832235Z&se=2013-07-03T17%3A34%3A32.4613735Z&sr=b&sp=r&sig=mJgQGW%2Fr3v8HN2%2BVV3Uady7J68nFqeHyzQb37HAhfuE%3D" 

Azure returns the following:

 HTTP/1.1 200 OK Content-Length: 19988911 Content-Type: application/octet-stream Charset=UTF-8 Last-Modified: Fri, 07 Jun 2013 16:44:50 GMT ETag: 0x8D031B57670B986 Server: Blob Service Version 1.0 Microsoft-HTTPAPI/2.0 x-ms-request-id: 77312761-65a9-42ef-90cd-ff718a80b231 Date: Wed, 03 Jul 2013 16:41:01 GMT 

Answer 1

We have received this fix.

As mentioned in @BrentDaCodeMonkey, Azure returns the expected response 206 if you are using API version 2011-01-18 or higher, but in our case we do not initiate the request, so we cannot specify this using the request header.

However, some Microsoft friends told us that you can install the global version of the API for the storage account, but for this you need to use the REST API (this is not what you can do in the management interface), This post explains. as:

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

After setting DefaultServiceVersion in 2011-01-18, we now return the expected status of 206 for RANGE requests.

Answer 2

I turned to some members of the product group and received the following ...

200 versus 206 due to gifts of the “-I” flag in the curl command. This results in a HEAD request instead of GET, which is essentially a call to get blob properties instead of get blob, which will ignore the range header. Also, do not forget to specify version headers as "x-ms-version: 2011-08-18" or later, since the range format "startByte-" was only supported in this version later.

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

Answer 3

Yes it works. I used SAS to stream video to mobile phones that use Range headers.

It is easy to verify with a bit of code.

Answer 4

For those struggling with the Azure Service API and complex authorization, I recommend this very simple C # snippet that does the same thing in the easiest 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 = await client.GetServicePropertiesAsync(); properties.DefaultServiceVersion = "2013-08-15"; await client.SetServicePropertiesAsync(properties);