從 URL 放置頁面
此 Put Page From URL 作業會將頁面範圍寫入至從 URL 讀取內容的分頁 Blob。 此 API 自 2018-11-09 版起提供。
要求
您可以建構 Put Page From URL 要求，如下所示。 建議您使用 HTTPS。 以您的記憶體帳戶名稱取代 myaccount ：
| PUT 方法要求 URI | HTTP 版本 |
|---|---|
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=page |
HTTP/1.1 |
模擬儲存體服務 URI
當您對模擬記憶體服務提出要求時，請將模擬器主機名和 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 儲存體提出要求。 |
Date 或 x-ms-date |
必要。 指定要求的「國際標準時間」(UTC)。 如需詳細資訊，請參閱授權對 Azure 儲存體提出要求。 |
x-ms-version |
所有已授權要求都需要。 指定用於這個要求的作業版本。 如需詳細資訊，請參閱 Azure 儲存體服務的版本。 |
Range |
需要 Range 或 x-ms-range。指定要以頁面寫入的位元組範圍。 您必須指定開始和結束範圍。 此標頭是由 HTTP/1.1 通訊協定規格所定義。 針對頁面更新作業，頁面範圍的大小上限為 4 MiB。 因為頁面必須對齊 512 位元組界限，所以開始位移必須是 512 的模數，而結束位移必須是 512 – 1 的模數。 有效位元組範圍的範例包括0-511、512-1023等等。 Blob 服務只接受標頭的單一位元組範圍 Range ，而且必須以下列格式指定位元組範圍： bytes=startByte-endByte。如果同時指定 Range 與 x-ms-range，服務會使用 x-ms-range 的值。 如需詳細資訊，請參閱 指定 Blob 服務作業的範圍標頭。 |
x-ms-range |
需要 Range 或 x-ms-range。指定要以頁面寫入的位元組範圍。 您必須指定開始和結束範圍。 此標頭是由 HTTP/1.1 通訊協定規格所定義。 頁面範圍的大小上限為 4 MiB。 因為頁面必須對齊 512 位元組界限，所以開始位移必須是 512 的模數，而結束位移必須是 512 – 1 的模數。 有效位元組範圍的範例包括0-511、512-1023等等。 Blob 服務只接受標頭的單一位元組範圍 x-ms-range ，而且必須以下列格式指定位元組範圍： bytes=startByte-endByte。如果同時指定 Range 與 x-ms-range，服務會使用 x-ms-range 的值。 如需詳細資訊，請參閱 指定 Blob 服務作業的範圍標頭。 |
Content-Length |
必要。 指定要求主體中所傳輸的位元組數目。 這個標頭的值必須設定為零。 當長度不是零時，作業會失敗，狀態代碼為 400 (不正確的要求) 。 |
x-ms-copy-source:name |
必要。 指定來源 Blob 的 URL。 此值可以是長度上限為 2 KiB 的 URL，指定 Blob。 此值應該像出現在要求 URI 中一樣以 URL 編碼。 來源 Blob 必須是公用，或必須透過共用存取簽章獲得授權。 如果來源 Blob 是公用的，則不需要授權才能執行作業。 以下是來源物件 URL 的一些範例： - https://myaccount.blob.core.windows.net/mycontainer/myblob- https://myaccount.blob.core.windows.net/mycontainer/myblob?snapshot=<DateTime>- https://myaccount.blob.core.windows.net/mycontainer/myblob?versionid=<DateTime> |
x-ms-copy-source-authorization: <scheme> <signature> |
選擇性。 指定複製來源的授權配置和簽章。 如需詳細資訊，請參閱授權對 Azure 儲存體提出要求。 Azure Active Directory 僅支援配置持有人。 2020-10-02 版和更新版本支援此標頭。 |
x-ms-source-range |
上傳指定範圍內來源 URL 中 Blob 的位元組。 您必須指定開始和結束範圍。 此標頭是由 HTTP/1.1 通訊協定規格所定義。 頁面範圍的大小上限為 4 MiB。 Blob 服務只接受標頭的單一位元組範圍 x-ms-source-range ，而且必須以下列格式指定位元組範圍： bytes=startByte-endByte。如需詳細資訊 ，請參閱指定 Blob 服務作業的範圍標頭 。 |
x-ms-source-content-md5 |
選擇性。 URI 中頁面內容的 MD5 哈希。 此哈希是用來在從 URI 傳輸數據期間驗證頁面的完整性。 當指定此標頭時，記憶體服務會比較從複製來源到達的內容哈希與這個標頭值。 注意：此 MD5 哈希不會與 Blob 一起儲存。 如果兩個哈希不相符，作業會失敗，錯誤碼為 400 (不正確的要求) 。 |
x-ms-source-content-crc64 |
選擇性。 URI 中頁面內容的CRC64哈希。 此哈希是用來在從 URI 傳輸數據期間驗證頁面的完整性。 當指定此標頭時，記憶體服務會比較從複製來源到達的內容哈希與這個標頭值。 注意：此 CRC64 哈希不會與 Blob 一起儲存。 如果兩個哈希不相符，作業會失敗，錯誤碼為 400 (不正確的要求) 。 如果和 x-ms-source-content-md5x-ms-source-content-crc64 標頭都存在，要求會失敗，並出現 400 (不正確的要求) 。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 值。 只有當 Blob 的 ETag 值不符合指定的值時，才指定此條件標頭的 ETag 值來寫入頁面。 如果兩值完全相同，Blob 服務會傳回狀態碼 412 (先決條件失敗)。 |
x-ms-encryption-scope |
選擇性。 指出用來加密來源內容的加密範圍。 2019-02-02 版和更新版本支援此標頭。 |
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-date: Fri, 16 Sep 2011 22:15:50 GMT
x-ms-version: 2018-11-09
x-ms-range: bytes=0-65535
x-ms-copy-source: https://myaccount.blob.core.windows.net/mycontainer/myblob
x-ms-source-range: bytes=0-65535
Authorization: SharedKey myaccount:4KdWDiTdA9HmIF9+WF/8WfYOpUrFhieGIT7f0av+GEI=
Content-Length: 0
回應
回應包括 HTTP 狀態碼和一組回應標頭。
狀態碼
成功的作業會傳回狀態碼「201 (已建立)」。
如需狀態代碼的詳細資訊，請參閱 狀態和錯誤碼。
回應標頭
這項作業的回應包括下列標頭。 回應也可能包括其他標準 HTTP 標頭。 所有標準標頭都符合 HTTP/1.1 通訊協議規格。
| 語法 | 描述 |
|---|---|
ETag |
Blob 的 ETag。 如果要求版本是 2011-08-18 和更新版本，ETag 值會以引號括住。 您可以針對 If-Match 或 If-None-Match 要求標頭指定 ETag 的值，以使用 ETag 執行條件式 Put Page From URL 作業。 |
Last-Modified |
上次修改 Blob 的時間與日期。 日期格式會依照 RFC 1123。 如需詳細資訊，請參閱 在標頭中代表日期/時間值。 Blob 上的任何寫入作業 (包括 Blob 的中繼資料或屬性更新) 都會變更 Blob 的上次修改時間。 |
Content-MD5 |
傳回 ，讓用戶端可以檢查訊息內容完整性。 此標頭的值是由 Blob 服務計算。 它不一定與要求標頭中指定的值相同。 針對 2019-02-02 版或更新版本，只有在要求具有此標頭時，才會傳回此標頭。 |
x-ms-content-crc64 |
針對 2019-02-02 版或更新版本。 傳回 ，讓用戶端可以檢查訊息內容完整性。 此標頭的值是由 Blob 服務計算。 它不一定與要求標頭中指定的值相同。 當要求中沒有標頭時 x-ms-source-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 |
可用來針對要求和對應的回應進行疑難解答。 如果此標頭存在於要求中，且值包含不超過 1,024 個可見的 ASCII 字元，則此標頭的值等於標頭的值 x-ms-client-request-id 。 x-ms-client-request-id如果要求中沒有標頭，它就不會出現在回應中。 |
回應本文
無。
範例回應
Response Status:
HTTP/1.1 201 Created
Response Headers:
Transfer-Encoding: chunked
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 From URL 作業，如下所述。
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 From URL作業所需的 RBAC 動作，以及包含此動作的最低特殊許可權內建 Azure RBAC 角色：
- Azure RBAC 動作：Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
- 最低特殊許可權的內建角色：記憶體 Blob 數據參與者
若要深入瞭解如何使用 Azure RBAC 指派角色，請參閱 指派 Azure 角色以存取 Blob 數據。
備註
Put Page From URL 作業會將頁面範圍寫入分頁 Blob。 此作業只能在現有的分頁 Blob 上呼叫。 無法呼叫它來建立新的分頁 Blob，也無法在區塊 Blob 上呼叫它。 使用目前不存在的 Blob 名稱呼叫 Put Page From URL 會傳回 BlobNotFound 錯誤， (HTTP 狀態代碼 404 – 找不到) 。
在 2020-10-02 版和更新版本中，複製作業的來源支援 Azure Active Directory 授權。
若要建立新的分頁 Blob，請呼叫 Put Blob ，並指定要建立為分頁 Blob 的 Blob 類型。 分頁 Blob 的大小上限為 8 TiB。
如果 Blob 有作用中的租用，客戶端必須在要求上指定有效的租用標識碼，才能寫入頁面。
頁面更新作業
呼叫 Put Page From URL 會在指定的分頁 Blob 上執行就地寫入。 指定頁面中的所有內容都會以更新的內容覆寫。
重要
如果伺服器逾時，或您的連線在 期間 Put Page From URL關閉，則頁面可能或可能尚未更新。 因此，您應該繼續重試更新，直到收到表示成功的回應。
針對更新作業提交 Put Page From URL 的每個頁面範圍，大小最多可達 4 MiB。 頁面的開始和結束範圍必須符合 512 位元組的界限。 如果您嘗試上傳大於 4 MiB 的頁面範圍，服務會傳回狀態代碼 413 (要求實體太大) 。
管理並行問題
Blob 服務會循序處理對重疊頁面的並行寫入。 也就是說，服務處理的最後一頁會決定 Blob 的內容。 因此，為了確保 Blob 內容的完整性，用戶端應該使用下列一或多種方法，處理重疊頁面的寫入：
您可以檢查每次成功呼叫
Put Page From URL的Last-Modified回應標頭值。 從 Blob 服務傳回的回應順序不一定對應至服務執行的順序。 但是，Last-Modified的值一律會指出服務處理要求的順序。您可以使用開放式並行存取，根據 Blob 的 ETag 或上次修改時間有條件地執行更新。 此方法適用於並行寫入數目較低的情況。 使用條件式要求標頭
If-Match、If-None-Match、If-Modified-Since及If-Unmodified-Since可達成此目的。您可以呼叫 租用 Blob ，以鎖定 Blob 以針對一分鐘期間的其他寫入鎖定 Blob，如果租用已更新，則為較長時間。
您可以使用 Blob 的序號，確保重試沒有回應的要求不會產生並行更新。 當用戶端需要提高頁面寫入的輸送量時，最適合使用此方法。 下一節將詳細說明。
使用分頁 Blob 序號重試要求
當呼叫 Put Page From URL 逾時或未傳回回應時，無法知道要求是否成功。 因此，您必須重試要求，但因為 Azure 記憶體服務的分散式本質，所以在重試要求成功之後，可以處理原始要求。 延遲的原始要求可能會覆寫其他更新，而產生非預期的結果。 下列順序說明如何發生此情況：
將
Put Page From URL值 「X」 寫入頁面 0 的要求逾時或未傳回回應。將值 "X" 寫入頁面 0 的重試要求成功。
將值 "Y" 寫入頁面 0 的要求成功。
原始要求成功，並將值 "X" 寫入頁面 0。
當用戶端預期值 "Y" 時，讀取頁面 0 卻傳回值 "X"。
當原始要求未在 100-499 之間傳回狀態代碼或 503 (伺服器忙碌) 時，就可能發生這種衝突。 如果傳回上述狀態碼之一，則可以確定要求成功或失敗。 但是，如果服務傳回此範圍以外的狀態碼，則無法確定原始要求的狀態。
若要避免這種衝突，您可以使用分頁 Blob 的序號來確保當您重試要求時，原始要求後續不會成功。 為了達成目的，您應該遞增序號，然後再重試原始要求。 接著，您可以使用條件式序號標頭，確保如果要求序號不符合預期的序號，要求就會失敗。 以下循序說明此方法：
用戶端會使用 Put Blob 建立分頁 Blob，並將其序號設定為 0。
將
Put Page From URL值 「X」 寫入頁面 0 的要求，if-sequence-number-lt其標頭設定為1逾時或未傳回回應。用戶端呼叫 Set Blob Properties，並將序號更新為 1。
將值 「X」 寫入頁面 0
if-sequence-number-lt且設定為2成功的重試要求。將值 「Y」 寫入頁面 0 的要求，其
if-sequence-number-lt設定為2成功。最終會處理原始要求，但失敗，因為它會指定序號必須小於 1 (即
if-sequence-num-lt標頭設定為1) 的條件。 錯誤為 SequenceNumberConditionNotMet (HTTP 狀態碼 412 - 先決條件失敗)。讀取頁面 0 傳回預期值 "Y"。