共用方式為


放置頁面

Put Page 作業會將頁面範圍寫入分頁 Blob。

要求

您可以建構 Put Page 要求,如下所示。 建議您使用 HTTPS。 以您的記憶體帳戶名稱取代 myaccount

PUT 方法要求 URI HTTP 版本
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=page HTTP/1.1

模擬記憶體服務要求

當您對模擬記憶體服務提出要求時,請將模擬器主機名和 Blob 服務埠指定為 127.0.0.1:10000,後面接著仿真的記憶體帳戶名稱:

PUT 方法要求 URI HTTP 版本
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=page HTTP/1.1

如需詳細資訊,請參閱使用 Azure 模擬器進行本機 Azure 儲存體開發

URI 參數

您可以在要求 URI 上指定下列其他參數:

參數 描述
timeout 選擇性。 timeout 參數以秒為單位。 如需詳細資訊,請參閱 設定 Blob 服務作業的逾時

要求標頭

下表說明必要的和選擇性要求標頭:

要求標頭 描述
Authorization 必要。 指定授權配置、帳戶名稱和簽章。 如需詳細資訊,請參閱授權對 Azure 儲存體提出要求
Datex-ms-date 必要。 指定要求的「國際標準時間」(UTC)。 如需詳細資訊,請參閱授權對 Azure 儲存體提出要求
x-ms-version 所有已授權要求都需要。 指定用於這個要求的作業版本。 如需詳細資訊,請參閱 Azure 儲存體服務的版本
Range 需要 Rangex-ms-range

指定要以頁面寫入的位元組範圍。 您必須指定開始和結束範圍。 此標頭是由 HTTP/1.1 通訊協定規格所定義。

針對 頁面更新 作業,頁面範圍最多可達 4 MiB。 針對 頁面清除 作業,頁面範圍可以和 Blob 的完整大小值一樣大。

因為頁面必須對齊 512 位元組界限,所以開始位移必須是 512 的模數,而結束位移必須是 512 –1 的模數。 有效位元組範圍的範例包括0-511、512-1023等等。

Blob 記憶體只接受標頭的單一位元組範圍 Range ,而且必須以下列格式指定位元組範圍: bytes=startByte-endByte

如果同時指定 Rangex-ms-range,服務會使用 x-ms-range 的值。 如需詳細資訊,請參閱 指定 Blob 服務作業的範圍標頭
x-ms-range 需要 Rangex-ms-range

指定要以頁面寫入的位元組範圍。 您必須指定開始和結束範圍。 此標頭是由 HTTP/1.1 通訊協定規格所定義。

針對頁面更新作業,頁面範圍的大小可以和 4 MiB 一樣大。 若為頁面清除作業,頁面範圍最大可以是 Blob 完整大小的值。

因為頁面必須對齊 512 位元組界限,所以開始位移必須是 512 的模數,而結束位移必須是 512 – 1 的模數。 有效的位元組範圍範例包括 0-511、512-1023 等。

Blob 記憶體只接受標頭的單一位元組範圍 x-ms-range ,而且必須以下列格式指定位元組範圍: bytes=startByte-endByte

如果同時指定 Rangex-ms-range,服務會使用 x-ms-range 的值。 如需詳細資訊 ,請參閱指定 Blob 服務作業的範圍標頭
Content-Length 必要。 指定要求主體中所傳輸的位元組數目。 x-ms-page-write當標頭設定為 clear時,這個標頭的值必須設定為 0
Content-MD5 選擇性。 頁面內容的 MD5 雜湊。 在傳輸期間,此雜湊可用來驗證頁面的完整性。 指定此標頭,儲存體服務會比較已到達的內容雜湊與此標頭值。
<br / >注意:此 MD5 哈希不會與 Blob 一起儲存。

如果兩個哈希不相符,作業會失敗,錯誤碼為 400 (不正確的要求) 。
x-ms-content-crc64 選擇性。 頁面內容的CRC64哈希。 在傳輸期間,此雜湊可用來驗證頁面的完整性。 指定此標頭,儲存體服務會比較已到達的內容雜湊與此標頭值。

注意:此 CRC64 哈希不會與 Blob 一起儲存。

如果兩個哈希不相符,作業會失敗,錯誤碼為 400 (不正確的要求) 。

Content-MD5如果 和 x-ms-content-crc64 標頭都存在,要求會失敗,並出現 400 (不正確的要求) 。

2019-02-02 版和更新版本支援此標頭。
x-ms-page-write: {update ¦ clear} 必要。 您可以指定以下其中一個選項:

- Update:將要求本文所指定的位元組寫入指定的範圍。 RangeContent-Length 標頭必須相符,才能執行更新。
- Clear:清除指定的範圍,並釋放用於該範圍之記憶體的空間。 若要清除範圍,請將 Content-Length 標頭設定為 0,並將標頭設定 Range 為值,指出要清除的範圍,上限為 Blob 大小上限。
x-ms-encryption-scope 選擇性。 表示用來加密要求內容的加密範圍。 2019-02-02 版和更新版本支援此標頭。
x-ms-lease-id:<ID> 如果 Blob 具有作用中租用,則為必要項目。 若要在具有作用中租用的 Blob 執行這項作業,請指定此標頭的有效租用識別碼。
x-ms-if-sequence-number-le: <num> 選擇性。 如果 Blob 的序號小於或等於指定的值,則要求會繼續進行。 否則,它會因為 SequenceNumberConditionNotMet 錯誤而失敗, (HTTP 狀態代碼 412 – 前置條件失敗) 。
x-ms-if-sequence-number-lt: <num> 選擇性。 如果 Blob 的序號小於指定的值,則要求會繼續進行。 否則,它會因為 SequenceNumberConditionNotMet 錯誤而失敗, (HTTP 狀態代碼 412 – 前置條件失敗) 。
x-ms-if-sequence-number-eq: <num> 選擇性。 如果 Blob 的序號等於指定的值,則要求會繼續進行。 否則,它會因為 SequenceNumberConditionNotMet 錯誤而失敗, (HTTP 狀態代碼 412 – 前置條件失敗) 。
If-Modified-Since 選擇性。 DateTime 值。 只有在指定日期/時間修改 Blob 時,才能指定此條件式標頭以寫入頁面。 如果 Blob 尚未修改,Blob 記憶體會傳回狀態代碼 412 (前置條件失敗) 。
If-Unmodified-Since 選擇性。 DateTime 值。 指定此條件式標頭,只有在 Blob 自指定的日期/時間以來尚未修改時,才寫入頁面。 如果 Blob 已修改,Blob 記憶體會傳回狀態代碼 412 (前置條件失敗) 。
If-Match 選擇性。 ETag 值。 只有在其 ETag 值符合指定值時,才能指定此條件式標頭的 ETag 值寫入頁面。 如果值不符合,Blob 記憶體會傳回狀態代碼 412 (前置條件失敗) 。
If-None-Match 選擇性。 ETag 值。

指定這個條件式標頭的 ETag 值,只有在 Blob 的 ETag 值不符合指定的值時,才會寫入頁面。 如果值相同,Blob 記憶體會傳回狀態代碼 412 (前置條件失敗) 。
x-ms-client-request-id 選擇性。 提供客戶端產生的不透明值,其中包含 1-kibibyte (KiB) 設定記錄時記錄在記錄中的字元限制。 強烈建議您使用此標頭,將用戶端活動與伺服器收到的要求相互關聯。 如需詳細資訊,請參閱監視 Azure Blob 儲存體

唯有在符合指定條件的情況下,此作業也可支援使用條件式標頭以執行作業。 如需詳細資訊,請參閱 指定 Blob 服務作業的條件式標頭

要求標頭 (客戶提供的加密金鑰)

從 2019-02-02 版開始,您可以在要求上指定下列標頭,以使用客戶提供的密鑰來加密 Blob。 使用客戶提供的金鑰進行加密 (,而對應的標頭集) 是選擇性的。

要求標頭 描述
x-ms-encryption-key 必要。 Base64 編碼的 AES-256 加密金鑰。
x-ms-encryption-key-sha256 必要。 加密金鑰的Base64編碼SHA256哈希。
x-ms-encryption-algorithm: AES256 必要。 指定要用於加密的演算法。 此標頭的值必須設定為 AES256

要求本文

要求主體包含頁面的內容。

範例要求:更新位元組範圍

  
Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=page HTTP/1.1  
  
Request Headers:  
x-ms-page-write: update  
x-ms-date: Fri, 16 Sep 2011 22:15:50 GMT  
x-ms-version: 2011-08-18  
x-ms-range: bytes=0-65535  
Authorization: SharedKey myaccount:4KdWDiTdA9HmIF9+WF/8WfYOpUrFhieGIT7f0av+GEI=  
Content-Length: 65536  
  

範例要求:清除位元組範圍

  
Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=page HTTP/1.1  
  
Request Headers:  
Range: bytes=1024-2048  
x-ms-page-write: clear  
x-ms-date: Sun, 25 Sep 2011 23:37:35 GMT  
x-ms-version: 2011-08-18  
Authorization: SharedKey myaccount:4KdWDiTdA9HmIF9+WF/8WfYOpUrFhieGIT7f0av+GEI=  
  

回應

回應包括 HTTP 狀態碼和一組回應標頭。

狀態碼

成功的作業會傳回狀態碼「201 (已建立)」。

如需狀態代碼的詳細資訊,請參閱 狀態和錯誤碼

回應標頭

這項作業的回應包括下列標頭。 回應也可能包括其他標準 HTTP 標頭。 所有標準標頭都符合 HTTP/1.1 通訊協議規格

語法 描述
ETag Blob 的 ETag。 如果要求版本是 2011-08-18 和更新版本,ETag 值會以引號括住。 您可以針對 If-MatchIf-None-Match 要求標頭指定 ETag 的值,以使用 ETag 執行條件式 Put Page 作業。
Last-Modified 上次修改 Blob 的日期和時間。 日期格式會依照 RFC 1123。 如需詳細資訊,請參閱 代表標頭中的日期/時間值

Blob 上的任何寫入作業 (包括 Blob 的中繼資料或屬性更新) 都會變更 Blob 的上次修改時間。
Content-MD5 傳回此標頭,以供用戶端檢查訊息內容完整性。 此標頭的值是由 Blob 記憶體計算。 它不一定與要求標頭中指定的值相同。 針對 2019-02-02 版和更新版本,只有在要求具有此標頭時,才會傳回此標頭。
x-ms-content-crc64 針對 2019-02-02 版或更新版本,會傳回此標頭,讓用戶端可以檢查訊息內容完整性。 此標頭的值是由 Blob 記憶體計算。 它不一定與要求標頭中指定的值相同。

當要求中沒有標頭時 Content-MD5 ,就會傳回此標頭。
x-ms-blob-sequence-number 分頁 Blob 目前的序號。
x-ms-request-id 可唯一識別所做的要求,並可用來對要求進行疑難解答。 如需詳細資訊,請參閱 針對 API 作業進行疑難解答
x-ms-version 指出用來執行要求的 Blob 服務版本。 針對針對 2009-09-19 版和更新版本提出的要求,會傳回此標頭。
Date 服務所產生的 UTC 日期/時間值,表示起始響應的時間。
x-ms-request-server-encrypted: true/false 版本 2015-12-11 和更新版本。 如果指定的演算法成功加密要求的內容,這個標頭的值就會設定 true 為 。 否則,會將值設定為 false
x-ms-encryption-key-sha256 版本 2019-02-02 和更新版本。 如果要求使用客戶提供的金鑰進行加密,則傳回 ,因此用戶端可以使用提供的密鑰,確保要求的內容已成功加密。
x-ms-encryption-scope 版本 2019-02-02 和更新版本。 如果要求使用加密範圍,則傳回 ,因此用戶端可以使用加密範圍來確保要求的內容已成功加密。
x-ms-client-request-id 可用來針對要求和對應的回應進行疑難解答。 如果此標頭存在於要求中,則此標頭的值等於標頭的值 x-ms-client-request-id ,且值不包含超過 1,024 個可見的 ASCII 字元。 x-ms-client-request-id如果要求中沒有標頭,則不會出現在回應中。

回應本文

無。

範例回應

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
x-ms-content-crc64: 77uWZTolTHU  
Date: Sun, 25 Sep 2011 22:33:35 GMT  
ETag: "0x8CB171BA9E94B0B"  
Last-Modified: Sun, 25 Sep 2011 12:13:31 GMT  
x-ms-version: 2011-08-18  
x-ms-blob-sequence-number: 0  
Content-Length: 0  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
  

授權

在 Azure 記憶體中呼叫任何數據存取作業時,需要授權。 您可以授權 Put Page 作業,如下所示。

重要

Microsoft 建議使用 Microsoft Entra ID 搭配受控識別來授權對 Azure 記憶體的要求。 相較於共用密鑰授權,Microsoft Entra ID 提供更高的安全性和方便使用。

Azure 記憶體支援使用 Microsoft Entra ID 來授權 Blob 數據的要求。 使用 Microsoft Entra ID,您可以使用 Azure 角色型存取控制 (Azure RBAC) ,將許可權授與安全性主體。 安全性主體可能是使用者、群組、應用程式服務主體或 Azure 受控識別。 安全性主體是由 Microsoft Entra ID 驗證,以傳回 OAuth 2.0 令牌。 權杖接著可以用來授權對 Blob 服務的要求。

若要深入瞭解使用 Microsoft Entra ID 授權,請參閱使用 Microsoft Entra ID 授權 Blob 的存取權。

權限

以下是 Microsoft Entra 使用者、群組、受控識別或服務主體呼叫Put Page作業所需的 RBAC 動作,以及包含此動作的最低特殊許可權 Azure RBAC 角色:

若要深入瞭解如何使用 Azure RBAC 指派角色,請參閱 指派 Azure 角色以存取 Blob 數據

備註

Put Page 作業會將頁面範圍寫入分頁 Blob。 此作業只能在現有的分頁 Blob 上呼叫。 無法呼叫以建立新的分頁 Blob,也無法在區塊 Blob 上呼叫。 使用目前不存在的 Blob 名稱呼叫 Put Page 會傳回 HTTP 狀態代碼 404 (找不到) 。

若要建立新的分頁 Blob,請呼叫 Put Blob ,並指定要建立為分頁 Blob 的 Blob 類型。 分頁 Blob 的大小最多可達 8 TiB。

如果 Blob 有作用中的租用,客戶端必須在要求上指定有效的租用標識碼,才能寫入頁面。

頁面更新作業

搭配 Update 選項呼叫 Put Page 可在指定的分頁 Blob 中執行就地寫入。 指定頁面中的所有內容都會以更新的內容覆寫。

重要

如果伺服器在作業期間 Put Page 逾時或您的連線已關閉,則頁面可能或可能尚未更新。 因此,您應該繼續重試更新,直到您收到指出成功的響應為止。

針對更新作業所 Put Page 提交的每一個頁面範圍,大小上限為 4 MiB。 頁面的開始和結束範圍必須符合 512 位元組的界限。 如果您嘗試上傳大於 4 MiB 的頁面範圍,服務會傳回狀態代碼 413 (要求實體太大) 。

頁面清除作業

使用 Clear 選項呼叫 Put Page 會釋放指定頁面所使用的儲存空間。 已清除的頁面將不會再當做分頁 Blob 的一部分追蹤。

已清除的頁面不再對記憶體帳戶產生費用,因為其記憶體資源已釋出。 唯一的例外是,如果有分頁 Blob 的現有快照集。 如果這些相同的頁面已不存在於來源 Blob 的一部分,則快照集中的頁面會產生費用。

管理並行問題

Blob 記憶體會循序處理對重迭頁面的並行寫入。 也就是說,服務所處理的最後一頁會決定 Blob 的內容。 因此,為了確保 Blob 內容的完整性,客戶端應該使用下列一或多個方法來處理重疊頁面的寫入:

  • 您可以檢查每次成功呼叫 Put PageLast-Modified 回應標頭值。 從 Blob 記憶體傳回的回應順序不一定對應至服務所執行的順序。 但是,Last-Modified 的值一律會指出服務處理要求的順序。

  • 您可以使用開放式並行存取,根據 Blob 的 ETag 或上次修改時間有條件地執行更新。 此方法適用於並行寫入數目較低的情況。 使用條件式要求標頭 If-MatchIf-None-MatchIf-Modified-SinceIf-Unmodified-Since 可達成此目的。

  • 您可以呼叫 租用 Blob 來鎖定 Blob,以針對一分鐘期間的其他寫入鎖定 Blob,如果租用已更新,則為更長的時間。

  • 您可以使用 Blob 的序號,以確保重試沒有回應的要求不會產生並行更新。 這種方法可能最適合需要頁面寫入高輸送量的用戶端。 下一節會詳細說明這一點。

使用分頁 Blob 序號重試要求

當呼叫 Put Page 逾時或未傳回回應時,無法知道特定要求是否成功。 因此,您必須重試要求,但因為 Azure 記憶體服務的分散式本質,因此在重試的要求成功之後,可能會處理原始要求。 延遲的原始要求可能會覆寫其他更新,而產生非預期的結果。 下列順序說明可能發生的情況:

  1. Put Page 值 「X」 寫入第 0 頁的要求逾時或未傳回回應。

  2. 將值 "X" 寫入頁面 0 的重試要求成功。

  3. 將值 "Y" 寫入頁面 0 的要求成功。

  4. 原始要求成功,並將值 "X" 寫入頁面 0。

  5. 當用戶端預期值 "Y" 時,讀取頁面 0 卻傳回值 "X"。

當原始要求未從 100 傳回狀態代碼到 499 或 503 (伺服器忙碌) 時,就可能發生這種衝突。 如果傳回上述狀態碼之一,則可以確定要求成功或失敗。 但是,如果服務傳回此範圍以外的狀態碼,則無法確定原始要求的狀態。

若要避免這種衝突,您可以使用分頁 Blob 的序號來確保當您重試要求時,原始要求將不會成功。 為了達成目的,您應該遞增序號,然後再重試原始要求。 然後,您可以使用條件式序號標頭,確保要求在序號不符合預期的序號時失敗。 以下循序說明此方法:

  1. 用戶端會建立 具有 Put Blob 的頁面 Blob ,並將其序號設定為 0

  2. Put Page將值 「X」 寫入第 0 頁的要求,if-sequence-number-lt其標頭設定為1逾時或未傳回回應。

  3. 用戶端會呼叫 Set Blob Properties ,將序號更新為 1

  4. 重試的要求,將值 「X」 寫入第 0 頁,且 if-sequence-number-lt 設定為 2 成功。

  5. 要求將值 「Y」 寫入頁面 0,且 if-sequence-number-lt 設定為 2 成功。

  6. 最終會處理原始要求,但失敗,因為它會指定序號必須小於 1 (的條件, if-sequence-num-lt 也就是標頭設定為 1) 。 錯誤為 SequenceNumberConditionNotMet (HTTP 狀態碼 412 - 先決條件失敗)。

  7. 讀取頁面 0 傳回預期值 "Y"。

另請參閱

授權對 Azure 記憶體的要求
狀態和錯誤碼
設定 Blob 服務作業的逾時