Previous Azure Storage versions
Azure Storage supports multiple versions. To make a request against Storage, you must specify the version that you want to use for that operation, unless the request is anonymous.
Available versions
The current version of Azure Storage is 2025-01-05, and using that version is recommended where possible. For information about the latest version, see Versioning for Azure Storage.
Additional supported versions include:
Requests authorized via shared access signature
A request made via a shared access signature is processed according to which version you use to generate the SAS. Versions 2013-08-15 and 2012-02-12 include a versioning parameter (SignedVersion, or sv), which specifies which version to use to authorize and run the SAS request.
Version 2012-02-12 and later
Requests with shared access signatures generated by using version 2012-02-12 or later require the SignedVersion (sv) parameter. SignedVersion indicates the service version used for authorization and for calling the API operation. If the x-ms-version header is passed on the request, it's ignored. Only the SignedVersion (sv) parameter determines the service version to use to process the request made via the shared access signature.
Note
For version 2013-08-15 and earlier, make sure that services that prepare and distribute shared access signature URLs (that is, shared access signature providers or generators) specify Azure Storage service versions that are understood by client software (that is, shared access signature consumers).
The following table indicates which services are supported for which version, for a request made via a shared access signature:
Value of SignedVersion (sv) parameter |
Supported services |
|---|---|
| 2015-12-11 | All (Azure Blob Storage, Azure Queue Storage, Azure Table Storage, and Azure Files) |
| 2015-04-05 | All (Blob Storage, Queue Storage, Table Storage, and Azure Files) |
| 2015-02-21 | All (Blob Storage, Queue Storage, Table Storage, and Azure Files) |
| 2014-02-14 | Blob Storage, Queue Storage, and Table Storage |
| 2013-08-15 | Blob Storage, Queue Storage, and Table Storage |
| 2012-02-12 | Blob Storage, Queue Storage, and Table Storage |
The following example shows a shared access signature that calls List Blobs by using sv=2013-08-15.
https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=list&sv=2013-08-15&si=readpolicy&sig=a39 %2BYozJhGp6miujGymjRpN8tsrQfLo9Z3i8IRyIpnQ%3d
In this example, the service authorizes and runs the request by using version 2013-08-15. The response won't include the Url element under the Blob element, because it was removed in the 2013-08-15 version.
If a client application uses a version of the Storage client library based on version 2012-02-12, and makes a request that uses this shared access signature, the client expects the Uri element. Therefore, the request fails with a NullReferenceException.
Versions prior to 2012-02-12 (Blob Storage only)
Blob Storage introduced shared access signatures in version 2009-07-17. Table Storage and Queue Storage introduced shared access signatures in version 2012-02-12, so shared access signature behavior prior to version 2012-02-12 applies only to Blob Storage.
Version 2012-02-12 also introduced the SignedVersion (sv) parameter, which enables the shared access signature generator to specify the version to use to process the request. A shared access signature generated with a version prior to 2012-02-12 can't specify the version to use to process the request, and so relies on the following rules for authorization and API execution:
If the request has a valid
x-ms-versionheader, the earliest valid version (2009-07-17) is used to interpret the shared access signature parameters. The version specified byx-ms-versionis used to perform the Blob Storage operation.If the request doesn't have an
x-ms-versionheader, and the owner has set the default version by using Set Blob Storage Properties, then version 2009-07-17 is used to interpret the parameters. The owner-specified default version is used to perform the Blob Storage operation.If the request doesn't have an
x-ms-versionheader, and the owner hasn't set a default version, Blob Storage uses the earliest valid version (2009-07-17) to interpret the parameters. If the container is public, and its access restrictions were set with a Set Container ACL operation that used version 2009-09-19 or later, version 2009-09-19 is used to perform the Blob Storage operation.If the request doesn't have an
x-ms-versionheader, and the owner hasn't set a default version, Blob Storage uses the earliest valid version (2009-07-17) to interpret the parameters. If the container access restrictions weren't set with a Set Container ACL operation that used version 2009-09-19 or later, the Blob Storage operation is performed by using the earliest version of the service.
The following table applies these rules to various scenarios, and assumes the SignedVersion parameter isn't included.
| Value of x-ms-version header | Version used to interpret parameters for authorization and authorization for Blob Storage | Version used to perform Blob Storage operation |
|---|---|---|
| None | Earliest valid shared access signature version (2009-07-17) | 2009-09-19 is used if the container was set to public by Set Container ACL by using version 2009-09-19 or later. Otherwise, the earliest version of Blob Storage is used. |
| 2011-08-18 | Earliest valid shared access signature version (2009-07-17) | 2011-08-18. |
| Any version XXXX-XX-XX | Earliest valid shared access signature version (2009-07-17) | Version XXXX-XX-XX |
Note
Microsoft recommends using version 2011-08-18 or later for scenarios that require quoted ETag values, or valid Accept-Ranges response headers. Browsers and other streaming clients require these headers for efficient download and retries.