Tuesday, August 11, 2009

New Windows Azure Blob Features – August 2009

by WindowsAzure via Windows Azure on 8/11/2009 8:07:58 PM

Today we are releasing a new set of features for Windows Azure Blob. Windows Azure Blob enables applications to store and manipulate large objects and files in the cloud. The blobs (files) can be up to 50GB in size for the CTP.

All changes for this release are versioned changes, using “x-ms-version: 2009-07-17”. All prior versions of commands executed against the storage system will continue to work, as we extend the capabilities of the existing commands and introduce new commands.

The features for this release are:

• Update Blob with PutBlockList – We have added the ability to update the contents of a blob The prior version of Azure Blob required you to re-upload the whole blob in order to change a single block of a blob. With this new version, PutBlockList now allows you to add blocks, remove blocks, replace blocks, shuffle the order or existing blocks, or any combination of these for an existing blob. The benefit of this new feature is that to perform these changes you only have to upload the blocks you want to add or change. PutBlockList now allows you to create a new version of the blob by choosing blocks from a combination of (a) the existing set of blocks that comprise the current blob from the committed block list and (b) the newly uploaded blocks from the uncommitted block list.
  
• Root Blob Container – We have provided the ability for all storage accounts to have a single root blob container.  This allows applications to store and reference blobs right off the domain address.    This allows you to store and access blobs using a sample URL as follows:

http://myaccount.blob.core.windows.net/picture.jpg

With this versioned change, we also changed the way applications perform operations on containers to make it explicit that it is a container operation instead of a blob operation.  For example, to create a container called pictures, this now looks like:

PUT http://myaccount.blob.core.windows.net/pictures?restype=container

Note, to use the root blob container “x-ms-version: 2009-07-17” must be specified.   Support for anonymous requests that do not require a x-ms-version HTTP header to be specified will be added in the future.

• Shared Access Signatures for Signed URLs – It is now possible to create signatures, with an expiration date, that can be given out to provide access to Azure Blobs without having to give out your private key or make the blob container public. Applications can now create these Signed Access Signatures and add these to requests to Azure Blobs to create Signed URLs. The below is an example showing a signature (all of the fields after the “?”) giving read access to all of the blobs in the pictures container up until July 20^th. The URL then shows using this signature to access the blob profile.jpg in the pictures container.
  
  GET http://myaccount.blob.core.windows.net/pictures/profile.jpg?se=2009-07-20&sr=c&sp=r&sig=xUXi%2f%2fxnETUHQoV0MGS06OkEiTo%3d
  
  You create a signature computing a hash over a canonicalization of the request using your storage account secret key. The signature can then be used as part of the URL to provide read, write, or delete access for blob requests. Note, Shared Access Signatures do not require the use of x-ms-version.

In addition to the above new features we made the following semantic changes as part of this versioned CTP release:

• Conditional Headers for Windows Azure Blobs and Queues – Previous versions left it ambiguous as to the meaning of a request that specified multiple conditional headers (e.g., If-Match, If-None-Match, If-Modified-Since and If-Unmodified-Since). We now only allow a single conditional header to be specified, or one of the two following combinations: (1) If-Match and If-Unmodified-Since, or (2) If-None-Match and If-Modified-Since.
  
• Windows Azure Blobs and “/” – Prior versions of Azure Blobs would trim off slashes from a blob name if multiple slashes occurred in a row and could misinterpret the request if the container name was empty. We changed this behavior and now use the blob name as is, without trimming off preceding or trailing slashes, and correctly fail a request with an empty container name.
  
• Table Query and All List Operations – The max timeout is now 30 seconds for listing Blobs, Blob Containers and Queues and for performing Table Queries.

Note that the above features for this new release are currently only available via the Windows Azure Storage REST interface. They will be part of a future release of the Windows Azure SDK and storage client library.

For more information, details about these new features can be found in the MSDN documentation here later today:

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

In addition, Steve Marx will have some examples on using the above new functionality on his blog soon:

http://blog.smarx.com/

As always, we appreciate any feedback you might have.

Brad Calder
Windows Azure Storage