附加來自 URL 的區塊
作業會將 Append Block From URL 新的數據區塊認可至現有附加 Blob 的結尾。
Append Block From URL只有在建立 Blob 且x-ms-blob-type設定AppendBlob為 時，才允許此作業。
Append Block From URL 只有在 2018-11-09 版或更新版本才支援。
要求
您可以依照下列方式建構 Append Block From URL 要求。 建議使用 HTTPS。 以記憶體帳戶的名稱取代 myaccount 。
| PUT 方法要求 URI | HTTP 版本 |
|---|---|
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=appendblock |
HTTP/1.1 |
當您對仿真的記憶體服務提出要求時，請將模擬器主機名和 Azure Blob 儲存體 埠指定為 127.0.0.1:10000，後面接著仿真的記憶體帳戶名稱。
| PUT 方法要求 URI | HTTP 版本 |
|---|---|
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=appendblock |
HTTP/1.1 |
如需詳細資訊，請參閱使用 Azure 模擬器進行本機 Azure 儲存體開發。
URI 參數
| 參數 | 描述 |
|---|---|
timeout |
選擇性。 timeout 參數以秒為單位。 如需詳細資訊，請參閱 設定 Blob 記憶體作業的逾時。 |
要求標頭
下表描述必要的和選用的要求標頭。
| 要求標頭 | 描述 |
|---|---|
Authorization |
必要。 指定授權配置、帳戶名稱和簽章。 如需詳細資訊 ，請參閱授權對 Azure 記憶體的要求 。 |
Date 或 x-ms-date |
必要。 指定要求的「國際標準時間」(UTC)。 如需詳細資訊，請參閱授權對 Azure 儲存體提出要求。 |
x-ms-version |
所有授權要求都需要。 指定用於這個要求的作業版本。 如需詳細資訊，請參閱 Azure 儲存體服務的版本。 |
Content-Length |
必要。 指定要求主體中所傳輸的位元組數目。 這個標頭的值必須設定為零。 當長度不是零時，作業將會失敗，錯誤碼為 400 (錯誤要求) 。 |
x-ms-copy-source:name |
必要。 指定來源 Blob 的 URL。 此值可以是長度上限為 2 KiB 的 URL，可指定 Blob。 值應該以 URL 編碼，因為它會出現在要求 URI 中。 來源 Blob 必須是公用，或必須透過共用存取簽章獲得授權。 如果來源 Blob 是公用的，則不需要授權才能執行作業。 以下是來源物件 URL 的一些範例：https://myaccount.blob.core.windows.net/mycontainer/myblobhttps://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 儲存體提出要求。 只有配置持有人支援 Microsoft Entra ID。 2020-10-02 版和更新版本支援此標頭。 |
x-ms-source-range |
選擇性。 只上傳指定範圍內來源 URL 中 Blob 的位元組。 如果未指定此專案，則會將整個來源 Blob 內容上傳為單一附加區塊。 如需詳細資訊 ，請參閱指定 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-md5 存在 和 x-ms-source-content-crc64 標頭，要求就會失敗，並出現 400 (不正確的要求) 。2019-02-02 版或更新版本支援此標頭。 |
x-ms-encryption-scope |
選擇性。 指出用來加密來源內容的加密範圍。 2019-02-02 版或更新版本支援此標頭。 |
x-ms-lease-id:<ID> |
如果 Blob 具有作用中租用，則為必要項目。 若要在具有作用中租用的 Blob 執行這項作業，請指定此標頭的有效租用識別碼。 |
x-ms-client-request-id |
選擇性。 提供客戶端產生的不透明值，其中包含 1-kibibyte (KiB) 設定記錄時記錄在記錄中的字元限制。 強烈建議您使用此標頭，將用戶端活動與伺服器收到的要求相互關聯。 如需詳細資訊，請參閱監視 Azure Blob 儲存體。 |
x-ms-blob-condition-maxsize |
選擇性的條件式標頭。 附加 Blob 允許的位元組長度上限。
Append Block From URL如果作業造成 Blob 超過該限制，或 Blob 大小已經大於此標頭中指定的值，則要求會失敗，並出現 412 (前置條件失敗) 。 |
x-ms-blob-condition-appendpos |
選擇性條件式標頭，僅用於 Append Block from URL 作業。 數位，表示要比較的位元組位移。
Append Block from URL 只有在附加位置等於這個數位時，才會成功。 如果不是，要求會失敗，並出現 412 (前置條件失敗) 。 |
此作業支援使用其他條件標頭，以確保只有在符合指定條件時，API 才會成功。 如需詳細資訊，請參閱 指定 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=appendblock HTTP/1.1
Request Headers:
x-ms-version: 2018-11-09
x-ms-date: <date>
x-ms-copy-source: https://myaccount.blob.core.windows.net/mycontainer/myblob
x-ms-source-range: bytes=0-65535
x-ms-blob-condition-appendpos: 2097152
x-ms-blob-condition-maxsize: 4194304
Authorization: SharedKey myaccount:J4ma1VuFnlJ7yfk/Gu1GxzbfdJloYmBPWlfhZ/xn7GI=
Content-Length: 0
If-Match: "0x8CB172A360EC34B"
回應
回應包括 HTTP 狀態碼和一組回應標頭。
狀態碼
成功的作業會傳回狀態碼「201 (已建立)」。 如需狀態代碼的相關信息，請參閱 狀態和錯誤碼。
回應標頭
這項作業的回應包括下列標頭。 回應也可能包括其他標準 HTTP 標頭。 所有標準標頭都符合 HTTP/1.1 通訊協議規格。
| 回應標頭 | 描述 |
|---|---|
Etag |
ETag包含引號中的值。 用戶端會使用 值來執行條件 PUT 式作業，方法是使用 If-Match 要求標頭。 |
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-request-id |
此標頭可唯一識別提出的要求，並可用於對要求進行疑難解答。 |
x-ms-version |
指出用來執行要求的 Blob 記憶體版本。 對 2009-09-19 及更新版本提出要求會傳回此標頭。 |
Date |
服務產生的 UTC 日期/時間值，可指出啟動回應的時間。 |
x-ms-blob-append-offset |
此回應標頭只會針對附加作業傳回。 它會傳回區塊認可所在的位移，以位元組為單位。 |
x-ms-blob-committed-block-count |
Blob 中存在的已認可區塊數目。 您可以使用此方法來控制可以完成多少個附加。 |
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 或更新版本。 如果要求使用加密範圍，則會傳回此標頭。 接著，用戶端可以使用加密範圍，確保已成功加密要求的內容。 |
範例回應
Response Status:
HTTP/1.1 201 Created
Response Headers:
Transfer-Encoding: chunked
x-ms-content-crc64: 77uWZTolTHU
Date: <date>
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
x-ms-blob-append-offset: 2097152
x-ms-blob-committed–block-count: 1000
授權
在 Azure 記憶體中呼叫任何數據存取作業時，需要授權。 您可以授權 Append Block From URL 作業，如下所述。
本節中的授權詳細數據適用於複製目的地。 如需複製來源授權的詳細資訊，請參閱要求標頭 x-ms-copy-source的詳細數據。
重要
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 使用者、群組、受控識別或服務主體呼叫Append Block From URL作業所需的 RBAC 動作，以及包含此動作的最低特殊許可權 Azure RBAC 角色：
- Azure RBAC 宏指令：Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action 或 Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
- 最低特殊許可權的內建角色：記憶體 Blob 數據參與者
若要深入瞭解如何使用 Azure RBAC 指派角色，請參閱 指派 Azure 角色以存取 Blob 數據。
備註
Append Block From URL 將區塊上傳至現有附加 Blob 的結尾。 在伺服器上呼叫成功之後，即可立即使用數據區塊。 每個附加 Blob 最多允許 50,000 個附加，其中。 每個區塊的大小都可以不同。
下表描述依服務版本允許的最大區塊和 Blob 大小：
| 服務版本 | 透過 Append Block From URL) 的區塊大小上限 ( |
Blob 大小上限 |
|---|---|---|
| 版本 2022-11-02 和更新版本 | 100 MiB (Preview) | 大約 4.75 TiB (100 MiB × 50,000 個區塊) |
| 2022-11-02 之前的版本 | 4 MiB | 大約 195 gibibytes (GiB) (4 MiB × 50,000 個區塊) |
在 2020-10-02 版和更新版本中，複製作業的來源支援 Microsoft Entra ID 授權。
Append Block From URL 只有在 Blob 已經存在時，才會成功。
使用 Append Block From URL 上傳的 Blob 不會公開區塊識別符，因此您無法針對附加 Blob 呼叫 取得封鎖清單 。 這樣做會導致錯誤。
您可以在要求上指定下列選擇性的條件式標頭：
x-ms-blob-condition-appendpos：您可以將此標頭設定為用戶端預期附加區塊的位元組位移。 只有在目前的位移符合用戶端指定的位移時，要求才會成功。 否則，要求會失敗，錯誤碼為 412 (前置條件失敗) 。使用單一寫入器的用戶端可以使用這個標頭來判斷作業成功時
Append Block From URL，即使網路失敗。x-ms-blob-condition-maxsize：用戶端可以使用這個標頭來確保附加作業不會增加 Blob 大小超過預期的位元組大小上限。 如果條件失敗，要求會失敗，錯誤碼為 412 (前置條件失敗) 。
如果您嘗試上傳大於允許大小的區塊，服務會傳回 HTTP 錯誤碼 413 (要求實體太大) 。 此服務也會在回應中傳回錯誤的其他資訊，包括區塊允許的位元組大小上限。 如果您嘗試上傳超過 50,000 個區塊，服務會傳回錯誤碼 409 (Conflict) 。
如果 Blob 有作用中租用，用戶端必須在要求上指定有效的租用識別碼，才能將區塊寫入 Blob。 如果用戶端未指定租用標識符，或指定無效的租用標識符，Blob 記憶體會傳回錯誤碼 412 (前置條件失敗) 。 如果用戶端指定租用標識碼，但 Blob 沒有作用中的租用，服務會傳回錯誤碼 412。
如果您在現有的區塊 Blob 或分頁 Blob 上呼叫 Append Block From URL ，服務會傳回錯誤碼 409 (Conflict) 。 如果您在不存在的 Blob 上呼叫 Append Block From URL ，服務會傳回錯誤碼 404 (找不到) 。
避免重複或延遲的附加
在單一寫入器案例中，用戶端可以使用條件標頭來檢查目前的位移，以避免重複的附加或延遲寫入 x-ms-blob-condition-appendpos 。 用戶端也可以藉由使用 If-Match以條件檢查 ETag 來避免重複或延遲。
在多個寫入器案例中，每個用戶端都可以使用條件式標頭。 這可能不適合效能。 針對最高的並行附加輸送量，應用程式應該處理其應用層中的備援附加和延遲附加。 例如，應用程式可以在要附加的數據中新增 epoch 或序號。
若要瞭解指定計費類別的定價，請參閱 Azure Blob 儲存體 定價。
計費
定價要求可能源自使用 Blob 記憶體 API 的用戶端，無論是直接透過 Blob 記憶體 REST API，還是來自 Azure 記憶體用戶端連結庫。 這些要求會累算每個交易的費用。 交易類型會影響帳戶的收費方式。 例如，讀取交易會累算到與寫入交易不同的計費類別。 下表顯示根據記憶體帳戶類型的要求計費類別 Append Block From URL ：
| 作業 | 儲存體帳戶類型 | 計費類別 |
|---|---|---|
| 附加封鎖來自 URL (目的地帳戶1) | 進階區塊 Blob 標準一般用途 v2 標準一般用途 v1 |
寫入作業 |
| 附加 [封鎖來源 URL] (來源帳戶2) | 進階區塊 Blob 標準一般用途 v2 標準一般用途 v1 |
讀取作業 |
1目的地帳戶會支付一筆交易來起始寫入的費用。
2來源帳戶會對來源的每個讀取要求產生一筆交易。