Dışarıya aktar (0) Yazdır
Tümünü Genişlet
EN
Bu içerik dilinizde bulunmamaktadır ancak İngilizce sürümüne buradan bakabilirsiniz.
2 / 3 bunu faydalı olarak değerlendirdi - Bu konuyu değerlendir

Versioning for the Blob, Queue, and Table Services in Azure

Updated: April 3, 2014

The Microsoft Azure Storage services accept requests that specify different versions of each operation. You can specify which version of an operation you want to use by setting the x-ms-version request header. Your code can call an older version of an operation, or you can modify your code to call a newer version. The documentation for each operation specifies behavior differences between different versions of the operation.

The x-ms-version request header value must be specified in the format YYYY-MM-DD. For example:

Request Headers:
x-ms-version: 2013-08-15

The following versions of the Windows Azure storage services are currently available:

For requests that do not use a shared access signature, the Windows Azure storage services do not require the x-ms-version header to be specified on the request. However, we recommend that you include this header on every request, especially authenticated requests. In addition, we recommend that you set a default version for the Blob service using the Set Blob Service Properties (REST API) operation.

Client software that uses a shared access signature URL could experience unexpected behavior when the SAS URL specifies a storage service version that is newer than the client software. Code that prepares and distributes shared access signature URLs should specify versions that are understood by client software that makes storage service requests.

Anonymous requests to the Blob service and authenticated requests to all services may or may not have a version specified. The following list indicates how these requests are evaluated and how the request is processed.

  1. If a request has a valid x-ms-version header, the storage service uses the specified version. All requests to the Table and Queue services that do not use a shared access signature must specify an x-ms-version header.

  2. If a request to the Blob service does not have an x-ms-version header, but the owner has set a default version using Set Blob Service Properties (REST API), then the owner-specified default version is used.

  3. If a request to the Blob service does not have an x-ms-version header and no default version has been set using Set Blob Service Properties (REST API), the earliest version of the Blob service is used, except when the container was last set to public with a Set Container ACL (REST API) operation performed using version 2009-09-19 or newer. In that case, the request uses version 2009-09-19.

The Blob service introduced shared access signatures in version 2009-07-17. The Table and Queue services introduced shared access signatures in version 2012-02-12. Prior to version 2012-02-12, the Table and Queue services only authenticated requests using SharedKey and SharedKeyLite.

Versioning impacts handling of shared access signature requests in two ways.

  • A version is determined for interpreting the parameters and behavior of the shared access signature.

  • A version is determined for performing the storage operation. For example, in versions before 2011-08-18, the Get Blob (REST API) operation does not return the Accept-Ranges header.

In version 2012-02-12 and newer, shared access signatures require a signedversion parameter, and this parameter cannot appear in requests that use earlier versions. When a shared access signature includes a signedversion parameter, the version it specifies is used both to interpret the SAS parameters and perform the storage operation. When possible, we recommend using version 2012-02-12 or newer with a signedversion parameter. For more information about signedversion and other SAS parameters, see Constructing the Shared Access Signature URI (REST API).

Shared access signatures to Table and Queue services always include the signedversion parameter. This section describes how the Blob service uses the x-ms-version request header when a shared access signature does not include a signedversion parameter. When a request to the Blob service omits the signedversion parameter, the request must use a version older than 2012-02-12, and version 2009-07-17 is used to interpret SAS parameters for the request.

When a SAS request does not include a signedversion parameter, the Blob service uses the following rules to determine the version used to interpret SAS parameters and behavior, and also determine the version used to perform the storage operation:

  1. If the Blob service SAS request has a valid x-ms-version header and does not have a signedversion field, version 2009-07-17 is used to interpret the SAS parameters, and the version specified by x-ms-version is used to perform the Blob service storage operation.

  2. If the Blob service SAS request does not have an x-ms-version header and does not contain a signedversion parameter, and the owner has set the default version for this storage service type using Set Blob Service Properties (REST API), version 2009-07-17 is used to interpret the SAS parameters and the owner-specified default version is used to perform the Blob service storage operation.

  3. If a Blob service SAS request does not have an x-ms-version header and does not have a signedversion parameter, and the owner has not set a default version, the Blob service uses version 2009-07-17 to interpret the SAS parameters. If the container is public and its access restrictions were set with a Set Container ACL (REST API) operation that used version 2009-09-19 or newer, version 2009-09-19 is used to perform the Blob service storage operation.

  4. If a Blob service SAS request does not have an x-ms-version header and does not have a signedversion parameter, and the owner has not set a default version, the storage service uses version 2009-07-17 to interpret the SAS parameters. If the container access restrictions were not set with a Set Container ACL (REST API) operation that used version 2009-09-19 or newer, the storage operation is performed using the earliest version of the Blob service.

The following table applies the above rules to various scenarios.

 

Value of x-ms-version header Value of signedversion parameter Version used to interpret SAS parameters and behavior Version used to perform storage operation

None

None

For Blob service resources, earliest SAS version (2009-07-17).

Error for Table and Queue services.

For Blob service resources, 2009-09-19 is used if the container was set to public by Set Container ACL (REST API) using version 2009-09-19 or newer, else earliest version of Blob service is used.

Error for Table and Queue services.

2011-08-18

None

For Blob service resources, earliest SAS version (2009-07-17).

Error for Table and Queue services.

For Blob service resources, 2011-08-18.

Error for Table and Queue services.

2012-02-12

None

For Blob service resources, earliest SAS version (2009-07-17).

Error for Table and Queue services.

For Blob service resources, 2012-02-12.

Error for Table and Queue services.

None

2012-02-12

2012-02-12

2012-02-12

2012-02-12

2012-02-12

2012-02-12

2012-02-12

2011-08-18

2012-02-12

2012-02-12

2012-02-12

Future version

2012-02-12

2012-02-12

2012-02-12

Future version A

Future version B

Future version B

Future version B

See Also

Bunu faydalı buldunuz mu?
(1500 karakter kaldı)
Geri bildiriminiz için teşekkür ederiz
Show:
© 2014 Microsoft. Tüm hakları saklıdır.