共用方式為

Azure 記憶體的版本控制

  • 發行項

Azure 記憶體支援多個版本。 若要對記憶體服務提出要求，您必須指定您想要用於該作業的版本，除非要求是匿名的。

Azure 記憶體服務的目前版本是 2024-11-04，建議您盡可能使用它。 如需所有其他支援版本的清單，以及使用每個版本的相關信息，請參閱 舊版 Azure 記憶體服務版本。

2024-11-04 服務版本包含下列功能：

  • 支援檔案服務中所有數據平面 API 的令牌型驗證。 如需詳細資訊，請參閱使用 Microsoft Entra IDAuthorize。
  • 支援進階檔案共享帳戶的付費高載。 此功能可以使用 建立共用 和 設定共用屬性 API 來啟用。
  • 在檔案服務中取得和設定檔案許可權時，支援二進位格式。 如需詳細資訊，請參閱 建立許可權 和 取得許可權

在要求中指定服務版本

如何指定要用於要求的記憶體服務版本，與該要求授權的方式有關。 下列各節說明授權選項，以及如何為每個選項指定服務版本。

  • 使用來自 Microsoft EntraOAuth 2.0 令牌的要求：若要使用 Microsoft Entra ID 授權要求，請使用 2017-11-09 版的服務版本在要求上傳遞 x-ms-version 標頭。 如需詳細資訊，請參閱 使用 OAuth 令牌呼叫記憶體作業，以 Microsoft Entra ID授權。

  • 使用共用金鑰或共用金鑰 Lite 的要求：若要使用共用金鑰或共用金鑰 Lite 授權要求，請在要求上傳遞 x-ms-version 標頭。 在 Azure Blob 記憶體的情況下，您可以呼叫 [設定 Blob 服務屬性]來指定所有要求的預設版本。

  • 使用共用存取簽章的要求 （SAS）：您可以在共用存取簽章上指定兩個版本設定選項。 選擇性 api-version 標頭會指出要用來執行 API 作業的服務版本。 必要的 SignedVersion (sv) 參數會指定要用來授權 SAS 提出要求的服務版本。 如果未指定 api-version 標頭，則 SignedVersion (sv) 參數的值也會指出用來執行 API 作業的版本。

  • 使用匿名存取的要求：針對 Blob 記憶體進行匿名存取時，不會傳入任何版本。 下一節會說明判斷要求使用哪個版本的啟發學習法。

使用 Microsoft Entra ID、共用金鑰或共用金鑰 Lite 授權要求

若要使用 Microsoft Entra ID、Shared Key 或 Shared Key Lite 授權要求，請在要求上指定 x-ms-version 標頭。 x-ms-version 要求標頭值必須以YYYY-MM-DD格式指定。 例如：

Request Headers:  
x-ms-version: 2020-04-08

下列規則描述如何評估這些要求，以判斷要用來處理要求的版本。

  • 如果要求具有有效的 x-ms-version 標頭，記憶體服務會使用指定的版本。 對不使用共用存取簽章的 Azure 資料表記憶體和 Azure 佇列記憶體的所有要求都必須指定 x-ms-version 標頭。 所有不使用共用存取簽章的 Blob 記憶體要求都必須指定 x-ms-version 標頭，除非已設定預設版本，如下一段所述。

  • 如果對 Blob 記憶體的要求沒有 x-ms-version 標頭，但帳戶擁有者已使用 設定 Blob 服務屬性 作業來設定預設版本，則會使用指定的預設版本作為要求的版本。

使用共用存取簽章授權要求

使用 2014-02-14 版或更新版本所產生的共用存取簽章 （SAS） 支援兩個版本控制選項：

  • api-version 查詢參數會定義 REST 通訊協定版本，以用來處理使用 SAS 提出的要求。

  • SignedVersion (sv) 查詢參數會定義要用於授權的SAS版本。

當用戶端使用 SAS 提出要求時，會使用 SignedVersion 查詢參數來進行授權。 授權參數，例如 si、sr、sp、sig、st、se、tn、spk、srk、epk和 erk，都會使用指定的版本來解譯。

REST 通訊協議參數，例如 rscc、rscd、rsce、rscl和 rsct，都是使用 api-version 參數標頭中提供的版本來強制執行。 如果未指定 api-version 標頭，則會使用提供給 SignedVersion 的服務版本。

api-version 參數不是授權標頭中字串登入的一部分，如 建立服務 SAS中所述。

下表說明當 SignedVersion 參數設定為 2014-02-14 版或更新版本時，服務會用於授權及呼叫 REST 通訊協定的版本設定配置。

api-version 參數的值 用於授權的版本 用於通訊協議行為的版本
未指定 sv 參數中指定的版本 sv 參數中指定的版本
任何格式為 XXXX-XX-XX 的有效記憶體服務版本 sv 參數中指定的版本 有效的記憶體服務版本 XXXX-XX-XX

範例 1

下列範例要求會使用 sv=2015-04-05呼叫 List Blobs，而不使用 api-version 參數。

https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=list&sv=2015-04-05&si=readpolicy&sig=a39 %2BYozJhGp6miujGymjRpN8tsrQfLo9Z3i8IRyIpnQ%3d

在此情況下，服務會使用 2015-04-05 版來驗證並授權要求，並使用 2015-04-05 版執行作業。

範例 2

下列範例要求會呼叫 使用 sv=2015-04-05 和 api-version 參數列出 Blob。

https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=list&sv=2015-04-05&si=readpolicy&sig=a39 %2BYozJhGp6miujGymjRpN8tsrQfLo9Z3i8IRyIpnQ%3d&api-version=2012-02-12

在這裡，服務會使用 2015-04-05 版來授權要求，並使用 2012-02-12 版執行作業。

注意

.NET 記憶體用戶端連結庫一律會將 REST 通訊協定版本（在 api-version 參數中）設定為其依據的版本。

透過匿名存取的要求

透過匿名存取所進行的要求會根據其所針對的記憶體帳戶類型，以不同的方式處理。

針對一般用途的記憶體帳戶

如果一般用途記憶體帳戶的匿名要求未指定 x-ms-version 標頭，且服務的預設版本尚未使用 Set Blob Service Properties來設定，則服務會使用最早的版本來處理要求。 不過，如果使用 2009-09-19 版或更新版本所執行的 設定容器 ACL 作業，則會使用 2009-09-19 版來處理要求。

針對 Blob 記憶體帳戶

如果 Blob 記憶體帳戶的匿名要求未指定 x-ms-version 標頭，而且服務的預設版本尚未使用 設定 Blob 服務屬性，則服務會使用最早的版本來處理要求。 針對 Blob 記憶體帳戶，最早的版本是 2014-02-14。

已知問題

本節詳細說明 Azure 記憶體 REST API 的已知問題。

InvalidHeaderValue 錯誤訊息

在罕見的情況下，進行直接 REST API 呼叫的應用程式可能會收到 InvalidHeaderValue 錯誤訊息。 此錯誤看起來類似下列範例：

HTTP/1.1 400 The value for one of the HTTP headers is not in the correct format.
Content-Length: 328
Content-Type: application/xml
Server: Microsoft-HTTPAPI/2.0
x-ms-request-id: <REMOVED>
Date: Fri, 19 May 2023 17:10:33 GMT
 
<?xml version="1.0" encoding="utf-8"?><Error><Code>InvalidHeaderValue</Code><Message>The value for one of the HTTP headers is not in the correct format.
RequestId:<REMOVED>
Time:2023-05-19T17:10:34.2972651Z</Message><HeaderName>x-ms-version</HeaderName><HeaderValue>yyyy-mm-dd</HeaderValue></Error>

建議您使用較早的 REST API 版本來查看問題是否已解決。 如果問題持續發生，或建議不可行，請 開啟支援票證，以討論進一步的選項。

另請參閱