Skip to main content

Azure Blob file download not resuming !

Azure Blobs are a scalable infrastructure to host\store files. I was working on understanding the behavior of large file uploads and downloads and create a reasonable strategy to support both scenarios in our application.

Azure blob file can be downloaded using any browser or internet download manager. For a public blob the url of file would suffice, but for downloading a private blob one needs to create a url containing the Secured Access Signature.

While testing downloads I realized that in case I pause and resume the download in Firefox or Chrome or any download manager the download restarts !!! I was expecting that the download should start from the place it paused. Imagine the scenario where we have uploaded half of a 2GB file and resuming the download would start over again !!! Clearly the Azure Blob storage was not supporting HTTP Range header.

As it turns out the Azure blob service is not a trivial file server. It is more of a Storage Application Server. It exposes an REST API to interact with it. The ability to support Range header(hence resume) was added in a later version of  Blob API.

The default API version that we interact with is 2009-09-19. This is the version used in case we do not specify any (version can be added in HTTP header x-ms-version). Since the browser does not send any custom version header while making the GET request we do not get the resume support.

The fix here was to update the blob service properties for our account using the Set Blob Service Properties API method. This method takes a parameter DefaultServiceVersion. This parameter defines the default version of blob API to use in case API version is not specified in the HTTP header. Setting this value to 2011-08-18 fixed the resume problem.

Now the browser was able resume broken downloads and download managers could even download in multiple chunks to improve download speed.

I did not find any option in the Azure Management portal that allows us to set the the above property so I had to do it using the REST API. I am sharing the code that I used to update the API version below


Eslam Hamouda said…
this code should work after the new changes to Azure assemblies :

var account = CloudStorageAccount.Parse("ConnectionString");
var blobs = account.CreateCloudBlobClient();
var existingprops = blobs.GetServiceProperties();
blobs.SetServiceProperties(new Microsoft.WindowsAzure.Storage.Shared.Protocol.ServiceProperties()
DefaultServiceVersion = "2011-08-18",
Logging = existingprops.Logging,
Metrics = existingprops.Metrics,

Thanks :)
chandermani said…
Thanks for sharing the information :)

Popular posts from this blog

Caching Images downloaded from web on Windows Phone Isolated storage

I was helping on a Windows Phone application where the requirement was to cache the images the phone downloads on the isolated storage for offline viewing.
I wanted a solution which was simple and as transparent as possible. While researching I found  someone wrote a Silverlight converter for loading images from isolated storage. Taking that as a base I created a converted which can
Load image from web (http + https), and persist it to isolated storage.In case of network connectivity issues can load the same image from isolated storage. It does that by mapping the http url to a isolated storage location.In case the network is down and the image is neither there in cache, loads a default image, passed as parameter to converter.Here is the gist for the implementation.

To use the converter
Import the name space.Declare the converter as resource.Set the Image Source Property to use this converter like this 

IIS Url Rewrite and HTTP POST data

If you play around with IIS Url Rewriting rules and try to do redirects on an HTTP POST you loose your POST data.

To make sure you get the post data you have to set the `redirectType` to `Temporary` within your rules. So the action configuration looks like this

<action redirectType="Temporary" type="Redirect" url="http://{HTTP_HOST}{REQUEST_URI}"> </action>
You may think what scenario warrant a POST request redirect. We faced one such scenario while doing SSO with a federated Identity Provider (IP)  such as Google, Azure AD. In federated authentication scenario once the user is authenticated by the IP, it redirects back to your site with claim tokens in a POST request over secure channel (https). In our case we wanted to redirect to user back http after receiving the request. But any redirects were causing loss of token. By doing a 307 (Temporary) redirect we were able to preserve the post data.