Put Block List操作は、ブロブを構成するブロックIDのリストを指定することでブロブを書き込みます。 ブロブの一部として書かれるためには、ブロックが以前の Put Block 操作でサーバーに正常に書き込まれている必要があります。
Put Block Listを呼び出して、変更されたブロックだけをアップロードし、新旧ブロックをまとめてコミットすることでブロブを更新できます。 コミットされたブロックリストからコミットするか、未コミットのブロックリストからコミットするか、または所属するブロックの最新バージョンをコミットするかを指定することでこれを実現できます。
依頼
Put Block List 要求は次のように構築できます。 HTTPS を使用することをお勧めします。
myaccountをストレージアカウント名に置き換えてください:
| PUTメソッドリクエストURI | HTTP バージョン |
|---|---|
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist |
HTTP/1.1 |
エミュレートされたストレージ サービス要求
エミュレートされたストレージサービスに対してリクエストを出す際は、エミュレーターのホスト名とBlobサービスポートを 127.0.0.1:10000指定し、その後にエミュレートされたストレージアカウント名を付けてください:
| PUTメソッドリクエストURI | HTTP バージョン |
|---|---|
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=blocklist |
HTTP/1.1 |
ストレージエミュレータは最大2ギビバイト(GiB)までのブロブサイズのみをサポートします。
詳細については、「ローカルの Azure Storage 開発に Azurite エミュレーターを使用する」を参照してください。
URI パラメーター
要求 URI には、次の追加パラメーターを指定できます。
| パラメーター | 説明 |
|---|---|
timeout |
このフィールドは省略可能です。
timeout パラメーターは秒単位で表されます。 詳細については、「 Set timeouts for Blob service operations」をご覧ください。 |
リクエストヘッダー
必須の要求ヘッダーと省略可能な要求ヘッダーを次の表に示します。
| リクエストヘッダー | 説明 |
|---|---|
Authorization |
必須。 承認スキーム、アカウント名、署名を指定します。 詳細については、「Azure Storageへの要求を承認する」を参照してください。 |
Date または x-ms-date |
必須。 要求の世界協定時刻 (UTC) を指定します。 詳細については、「Azure Storageへの要求を承認する」を参照してください。 |
x-ms-version |
すべての承認された要求に必要です。 この要求に使用する操作のバージョンを指定します。 詳細については、Azure Storage サービスのバージョン管理の |
Content-Length |
必須。 リクエスト内容の長さ(バイト単位)。 このヘッダーはブロックのリストの内容長さを指しており、ブロブ自体の長さではありません。 |
Content-MD5 |
このフィールドは省略可能です。 要求コンテンツの MD5 ハッシュ。 このハッシュは、トランスポート中に要求コンテンツの整合性を検証するために使用されます。 2 つのハッシュが一致しない場合、操作はエラー コード 400 (無効な要求) で失敗します。 このヘッダーはリクエスト内容に関連付けられており、ブロブ自体の内容とは関係ありません。 |
x-ms-content-crc64 |
このフィールドは省略可能です。 リクエストコンテンツのCRC64ハッシュ。 このハッシュは、トランスポート中に要求コンテンツの整合性を検証するために使用されます。 2 つのハッシュが一致しない場合、操作はエラー コード 400 (無効な要求) で失敗します。 このヘッダーはリクエスト内容に関連付けられており、ブロブ自体の内容とは関係ありません。 Content-MD5とx-ms-content-crc64の両方のヘッダーが存在する場合、リクエストは400(悪いリクエスト)で失敗します。 このヘッダーはバージョン2019-02-02以降でサポートされています。 |
x-ms-blob-cache-control |
このフィールドは省略可能です。 ブロブのキャッシュコントロールを設定します。 このプロパティが指定されている場合、それはブロブと一緒に保存され、読み取りリクエストで返されます。 リクエストでプロパティが指定されていなければ、リクエストが成功するとBlobでクリアされます。 |
x-ms-blob-content-type |
このフィールドは省略可能です。 ブロブのコンテンツタイプを設定します。 もし指定されていれば、このプロパティはブロブと一緒に保存され、読み取り要求で返されます。 コンテンツタイプが指定されていない場合は、デフォルトのタイプである application/octet-streamに設定されます。 |
x-ms-blob-content-encoding |
このフィールドは省略可能です。 ブロブのコンテンツエンコーディングを設定します。 もし指定されていれば、このプロパティはブロブと一緒に保存され、読み取り要求で返されます。 リクエストでプロパティが指定されていなければ、リクエストが成功するとBlobでクリアされます。 |
x-ms-blob-content-language |
このフィールドは省略可能です。 ブロブのコンテンツ言語を設定します。 もし指定されていれば、このプロパティはブロブと一緒に保存され、読み取り要求で返されます。 リクエストでプロパティが指定されていなければ、リクエストが成功するとBlobでクリアされます。 |
x-ms-blob-content-md5 |
このフィールドは省略可能です。 BLOB コンテンツの MD5 ハッシュ。 このハッシュは検証されません。なぜなら、各ブロックのハッシュはアップロード時に検証されているからです。 Get Blob操作は、このヘッダーの値をContent-MD5のレスポンスヘッダーに返します。 このプロパティがリクエストで指定されていなければ、リクエストが成功するとBlobのそのプロパティはクリアされます。 |
x-ms-meta-name:value |
このフィールドは省略可能です。 ブロブに関連付けられたユーザー定義の名前と値のペア。 バージョン2009-09-19以降、メタデータ名は C#識別子の命名ルールに従う必要があります。 |
x-ms-encryption-scope |
このフィールドは省略可能です。 ブロブを暗号化するために使用する暗号化範囲を示します。 この値は、コミットされるすべてのブロックを暗号化するために使われる暗号化範囲と一致しなければなりません。 このヘッダーはバージョン2019-02-02以降でサポートされています。 |
x-ms-encryption-context |
このフィールドは省略可能です。 デフォルトは「空」です。 値が設定されると、ブロブシステムのメタデータが設定されます。 最大長さ:1024。 アカウントに対して階層型名前空間が有効になっている場合にのみ有効です。 このヘッダーは2021-08-06以降のバージョンでサポートされています。 |
x-ms-tags |
このフィールドは省略可能です。 指定されたクエリ文字列でエンコードされたタグをブロブに設定します。 詳細については、 コメント 欄をご覧ください。 バージョン 2019-12-12 以降でサポートされています。 |
x-ms-lease-id:<ID> |
BLOBにアクティブなリースがある場合は必要となります。 アクティブなリースを持つ BLOB でこの操作を実行するには、このヘッダーの有効なリース ID を指定します。 |
x-ms-client-request-id |
このフィールドは省略可能です。 ストレージ分析ログの設定時に、クライアント生成の不透明な値と1キビバイト(KiB)の文字制限を提供します。 このヘッダーを使用して、クライアント側のアクティビティと、サーバーが受信する要求を関連付けすることを強くお勧めします。 |
x-ms-blob-content-disposition |
このフィールドは省略可能です。 ブロブの Content-Disposition ヘッダーを設定します。 バージョン 2013-08-15 以降で使用できます。Content-Dispositionヘッダーフィールドはレスポンスペイロードの処理方法に関する追加情報を伝え、追加のメタデータを付ける際に利用できます。 例えば、 attachmentに設定されている場合、このヘッダーはユーザーエージェントが応答を表示せず、「名前を付けて保存」ダイアログを表示するべきであることを示します。Get BlobおよびGet Blobプロパティ操作からの応答にはcontent-dispositionヘッダーが含まれています。 |
x-ms-access-tier |
このフィールドは省略可能です。 バージョン2018-11-09以降。 ブロブに設定すべきティアを示します。 ブロックブロブの場合、このヘッダーはバージョン2018-11-09以降のブロブストレージまたは汎用v2アカウントでのみサポートされています。 ブロックブロブの階層の有効な値は、 Hot、 Cool、 Cold、 Smart 、 Archiveです。注: Cold レベルは、バージョン 2021-12-02 以降でサポートされています。
Smart このティアはバージョン2026-02-06以降でサポートされており、現在パブリックプレビュー中です。ブロックのブロブ階層化に関する詳細は「 ブロブストレージ階層」を参照してください。 |
x-ms-immutability-policy-until-date |
バージョン 2020-06-12 以降。 ブロブに設定する保持 までの 日付を指定します。 これは、BLOB が変更または削除されないように保護できる日付です。 フォーマットRFC1123。 |
x-ms-immutability-policy-mode |
バージョン 2020-06-12 以降。 ブロブに対して設定すべき不変性ポリシーモードを指定します。 有効値は unlocked または locked です。
unlocked値は、ユーザーが保持期限を増減することでポリシーを変更できることを示しています。
lockedの値はこれらの行為が禁止されていることを示しています。 |
x-ms-legal-hold |
バージョン 2020-06-12 以降。 ブロブに設定する法的保留を指定します。 有効な値は、true および false です。 |
x-ms-expiry-option |
このフィールドは省略可能です。 バージョン2023-08-03以降。 リクエストの有効期限オプションを指定しています。 ExpiryOptionを参照してください。 このヘッダーは階層的な名前空間が有効であるアカウントに有効です。 |
x-ms-expiry-time |
このフィールドは省略可能です。 バージョン2023-08-03以降。 ブロブが期限切れに設定された時刻を指定します。 有効期限の形式は x-ms-expiry-optionによって異なります。 詳細は ExpiryOptionをご覧ください。 このヘッダーは階層的な名前空間が有効であるアカウントに有効です。 すでにブロブ上にある expiryTime は、リクエストに新しい値が含まれていない場合はクリアされません expiryTime |
この操作は、指定された条件が満たされた場合にのみ条件付きヘッダーを使ってブロックリストをコミットすることもサポートしています。 詳細については、「Blob Storage 操作の条件付きヘッダーを指定する」を参照してください。
要求ヘッダー (顧客提供の暗号化キー)
バージョン2019-02-02以降、顧客提供の鍵でブロブを暗号化するリクエストで以下のヘッダーを指定できます。 お客様が指定したキー (および対応するヘッダーのセット) による暗号化はオプションです。
| リクエストヘッダー | 説明 |
|---|---|
x-ms-encryption-key |
必須。 Base64 でエンコードされた AES-256 暗号化キー。 |
x-ms-encryption-key-sha256 |
必須。 暗号化キーの Base64 でエンコードされた SHA256 ハッシュ。 |
x-ms-encryption-algorithm: AES256 |
必須。 暗号化に使用するアルゴリズムを指定します。 このヘッダーの値は AES256 である必要があります。 |
リクエスト本文
リクエスト本体で、Blob Storageがリクエストされたブロックに対してチェックすべきブロックリストを指定することができます。 このようにして、既存のブロブを個々のブロックを挿入・置換・削除することで更新でき、ブロブ全体を再アップロードするのではありません。 変更されたブロックをアップロードした後、新しいブロックと保持したい既存のブロックを一緒にコミットして新しいバージョンのブロブをコミットできます。
Blobを更新するには、サービスがコミットブロックリスト、未コミットブロックリスト、または未コミットブロックリストからブロックIDを探すように指定できます。 どのアプローチを使うかを示すには、リクエストボディ内の適切なXML要素内のブロックIDを以下のように指定してください。
Committed要素内でブロックIDを指定すると、Blob Storageは指定されたブロックに対してコミットされたブロックリストのみを検索するよう指示します。 コミットされたブロックリストにブロックが見つからなければ、それはブロブの一部として書かれず、ブロブストレージはステータスコード400(悪いリクエスト)を返します。Uncommitted要素内でブロックIDを指定すると、Blob Storageは指定されたブロックに対して未コミットのブロックリストのみを検索するよう指示します。 未コミットのブロックリストにブロックが見つからなければ、それはBlobの一部として書き込まれず、Blob Storageはステータスコード400(Bad Request)を返します。Latest要素内でブロックIDを指定し、Blob Storageがまず未コミットのブロックリストを検索することを示します。 ブロックが未コミットリストにあれば、そのバージョンは最新のものであり、ブロブに書き込まれるべきです。 未コミットリストにブロックが見つからなければ、サービスはコミット済みブロックリストから名前付きブロックを検索し、見つかればそのブロックをブロブに書き込むべきです。
このバージョンの Put Block List のリクエストボディは以下のXML形式を使用しています。
<?xml version="1.0" encoding="utf-8"?>
<BlockList>
<Committed>first-base64-encoded-block-id</Committed>
<Uncommitted>second-base64-encoded-block-id</Uncommitted>
<Latest>third-base64-encoded-block-id</Latest>
...
</BlockList>
サンプルリクエスト
Put Block Listを示すために、コミットしたいブロックを3つアップロードしたと仮定します。 以下の例では、リストに記載された各ブロックの最新バージョンを使用するべきであることを示し、新しいブロブをコミットします。 これらのブロックがすでにコミットされているかどうかを知る必要はありません。
Request Syntax:
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1
Request Headers:
x-ms-date: Wed, 31 Aug 2011 00:17:43 GMT
x-ms-version: 2011-08-18
Content-Type: text/plain; charset=UTF-8
Authorization: SharedKey myaccount:DJ5QZSVONZ64vAhnN/wxcU+Pt5HQSLAiLITlAU76Lx8=
Content-Length: 133
Request Body:
<?xml version="1.0" encoding="utf-8"?>
<BlockList>
<Latest>AAAAAA==</Latest>
<Latest>AQAAAA==</Latest>
<Latest>AZAAAA==</Latest>
</BlockList>
次に、ブロブを更新したいと仮定します。 新しいブロブには以下の変更点があります:
ID
ANAAAA==の新しいブロックです。 このブロックはまず Put Blockへの呼び出しでアップロードされ、Put Block List呼び出しまで未コミットのブロックリストに表示されます。IDが
AZAAAA==されたブロックの更新版です。 このブロックはまず Put Blockへの呼び出しでアップロードされ、Put Block List呼び出しまで未コミットのブロックリストに表示されます。ID
AAAAAA==でブロックを外す。 このブロックは次のPut Block List呼び出しに含まれないため、ブロックは事実上ブロブから外されます。
以下の例は、ブロブを更新する Put Block List 呼び出しを示しています。
Request Syntax:
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1
Request Headers:
x-ms-date: Wed, 31 Aug 2009 00:17:43 GMT
x-ms-version: 2011-08-18
Content-Type: text/plain; charset=UTF-8
x-ms-expiry-option: RelativeToNow
x-ms-expiry-time: 30000
Authorization: SharedKey myaccount:DJ5QZSVONZ64vAhnN/wxcU+Pt5HQSLAiLITlAU76Lx8=
Content-Length: 133
Request Body:
<?xml version="1.0" encoding="utf-8"?>
<BlockList>
<Uncommitted>ANAAAA==</Uncommitted>
<Committed>AQAAAA==</Committed>
<Uncommitted>AZAAAA==</Uncommitted>
</BlockList>
応答
応答には、HTTP 状態コードと一連の応答ヘッダーが含まれます。
ステータスコード
操作が成功すると、状態コード 201 (Created) が返されます。
状態コードの詳細については、「状態コードとエラー コードを参照してください。
応答ヘッダー
この操作の応答には、次のヘッダーが含まれます。 応答には、追加の標準 HTTP ヘッダーも含まれる場合があります。 すべての標準ヘッダーは、HTTP/1.1 プロトコル仕様に準拠しています。
| 応答 | 説明 |
|---|---|
ETag |
エンティティタグには、クライアントがIf-Matchリクエストヘッダーを使って条件付きGET/PUT操作を行うことができる値を含みます。 要求バージョンが 2011-08-18 以降の場合、ETag 値は引用符で囲まれます。 |
Last-Modified |
BLOB が最後に変更された日付/時刻。 日付形式は RFC 1123 に従います。 詳細については、「ヘッダーの日付/時刻値を表す」を参照してください。 BLOB のメタデータやプロパティの更新など、BLOB を変更する操作は、BLOB の最終変更時刻を変更します。 |
Content-MD5 |
クライアントがメッセージ コンテンツの整合性を確認できるように返されます。 このヘッダーはリクエストの内容(この場合、ブロックのリストであり、ブロブ自体の内容ではありません)を指します。 バージョン2019-02-02以降では、このヘッダーはリクエストにこのヘッダーがある場合のみ返されます。 |
x-ms-content-crc64 |
バージョン2019-02-02以降では、このヘッダーが返され、クライアントがメッセージの内容の整合性をチェックできます。 このヘッダーはリクエストの内容(この場合、ブロックのリストであり、ブロブ自体の内容ではありません)を指します。 このヘッダーはリクエストに Content-md5 が存在しない場合に返されます。 |
x-ms-request-id |
作成された要求を一意に識別し、それを使用して要求のトラブルシューティングを行うことができます。 詳細については、「API 操作のトラブルシューティング」を参照してください。 |
x-ms-version |
リクエストを実行するために使われるBlob Storageのバージョンです。 このヘッダーは、バージョン 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-version-id: <DateTime> |
バージョン 2019-12-12 以降。 BLOB を一意に識別する不透明な DateTime 値を返します。 このヘッダーの値はブロブのバージョンを示し、その後のリクエストでブロブへのアクセスに利用できます。 |
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 00:17:44 GMT
ETag: “0x8CB172A360EC34B”
Last-Modified: Sun, 25 Sep 2011 00:17:43 GMT
x-ms-version: 2011-08-18
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
x-ms-version-id: <DateTime>
認可
Azure Storage でデータ アクセス操作を呼び出す場合は、承認が必要です。 次の説明に従って、Put Block List 操作を承認できます。
リクエストが x-ms-tags リクエストヘッダーでタグを指定する場合、呼び出し者は Set Blob Tags 操作の認可要件を満たす必要があります。
Important
Microsoft では、マネージド ID で Microsoft Entra ID を使用して、Azure Storage への要求を承認することをお勧めします。 Microsoft Entra ID は、共有キーの承認と比較して優れたセキュリティと使いやすさを提供します。
Azure Storage では、Microsoft Entra ID を使用して BLOB データへの要求を承認できます。 Microsoft Entra ID を使用すると、Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、セキュリティ プリンシパルにアクセス許可を付与できます。 セキュリティ プリンシパルには、ユーザー、グループ、アプリケーション サービス プリンシパル、または Azure マネージド ID を指定できます。 セキュリティ プリンシパルは、OAuth 2.0 トークンを返すために Microsoft Entra ID によって認証されます。 その後、トークンを使用して、BLOB サービスに対する要求を承認できます。
Microsoft Entra ID を使用した承認の詳細については、「Microsoft Entra IDを使用して BLOB へのアクセスを承認する」を参照してください。
アクセス許可
Microsoft Entra ユーザー、グループ、マネージド ID、またはサービス プリンシパルが Put Block List 操作を呼び出すために必要な RBAC アクションと、このアクションを含む最小特権の組み込み Azure RBAC ロールを次に示します。
- Azure RBAC action:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
- 最小特権の組み込みロール:Storage Blob Data Contributor
Azure RBAC を使用したロールの割り当ての詳細については、「BLOB データにアクセスするための Azure ロールの割り当て」を参照してください。
注釈
Put Block List操作はブロックを組み合わせてブロブを作る順序を強制します。
同じブロックIDはブロックリスト内で複数回指定できます。 ブロックIDが複数回指定されている場合、それは最終的にコミットされたブロブのブロックリスト内の各位置のバイト範囲を表します。 リスト内に複数回現れるブロックIDは、同じブロックリスト内で両方のインスタンスを指定しなければなりません。 言い換えれば、両方のインスタンスは Committed 要素、 Uncommitted 要素、または Latest 要素内で指定されなければなりません。
Put Block Listを使えば、既存のブロブを挿入、更新、削除で変更でき、全体を再度アップロードする必要はありません。 現在コミットされているブロックリストと未コミットのブロックリストの両方からブロックIDを指定して、新しいブロブを作成したり、既存のブロブの内容を更新したりできます。 この方法では、未コミットブロックリストからいくつかの新しいブロックを指定し、既に既存のブロックリストに含まれているコミットブロックリストから残りを指定することで、ブロブを更新できます。
Latest要素でブロックIDが指定され、コミットされたブロックリストと未コミットのブロックリストの両方に同じブロックIDが存在する場合、Put Block Listはコミットされていないブロックリストからブロックをコミットします。 コミットされたブロックリストにブロックIDが存在するが、コミットされていないブロックリストには存在しない場合、 Put Block List コミットされたブロックリストからブロックをコミットします。
ブロックブロブ内の各ブロックは異なるサイズになり得ます。 ブロックブロブは最大50,000個のコミットブロックを含めます。 ブロブに関連付けられる未コミットブロックの最大数は100,000です。
以下の表は、サービスバージョンごとに許容される最大ブロックおよびブロブサイズを示しています。
| サービスのバージョン | 最大ブロックサイズ( Put Block経由) |
最大ブロブサイズ( Put Block List経由) |
単一書き込み操作による最大ブロブサイズ( Put Blob経由) |
|---|---|---|---|
| バージョン 2019-12-12 以降 | 4,000メビバイト(MiB) | 約190.7テビバイト(TiB)(4,000MiB×50,000ブロック) | 5,000 MiB |
| バージョン 2016-05-31 から 2019-07-07 | 100 MiB | 約4.75 TiB(50,000ブロック×100 MiB) | 256 MiB |
| 2016年5月31日以前のバージョン | 4 MiB | 約195 GiB(50,000ブロック×4 MiB) | 64 MiB |
既存のブロブを更新するために Put Block List を呼び出すと、そのブロブの既存のプロパティやメタデータが上書きされます。 しかし、既存のスナップショットはブロブとともに保持されます。 条件付きリクエストヘッダーを使って操作を行うのは、指定された条件が満たされた場合のみです。
Put Block List操作がブロックの欠落で失敗した場合は、そのブロックをアップロードする必要があります。
未コミットのブロックは、最後の成功したPut Block操作から1週間以内にブロブへのPut BlockやPut Block Listへの成功した呼び出しがなければガットコレクションされます。 BLOB で Put Blob が呼び出されると、コミットされていないブロックはガベージ コレクションされます。
x-ms-tagsヘッダーにタグが記載されている場合、それらはクエリ文字列でエンコードされなければなりません。 タグキーと値は、 Set Blob Tagsで指定された命名および長さの要件に準拠しなければなりません。 さらに、 x-ms-tags ヘッダーには最大2 KiBサイズのタグを含めることができます。 タグが増える場合はSet Blob Tags 操作をご利用ください。
ブロブがアクティブなリースを持っている場合、クライアントはブロックリストをコミットするためにリクエスト時に有効なリースIDを指定しなければなりません。 クライアントがリース ID を指定しない場合、または無効なリース ID を指定した場合、Blob Storage はステータス コード 412 (前提条件に失敗しました) を返します。 クライアントがリースIDを指定しても、ブロブにアクティブなリースがない場合、Blob Storageはステータスコード412(前提条件失敗)も返します。 クライアントがまだ存在しないBlobのリースIDを指定する場合、Blob Storageはバージョン2013-08-15以降のリクエストに対してステータスコード412(Precondition Failed)を返します。 以前のバージョンでは、Blob Storageはステータスコード201(作成済み)を返します。
ブロブにアクティブなリースがあり、 Put Block List に連絡して更新すれば、リースは更新されたブロブ上で維持されます。
Put Block List ブロックの塊にのみ適用されます。 ページブロブで Put Block List を呼び出すとステータスコード400(悪いリクエスト)が表示されます。
archiveブロブの上書きは失敗します。 そうでなければ、 x-ms-access-tier ヘッダーが提供されていない場合、ブロブが古いブロブからティアを引き継ぎます。
請求書
価格要求は、Blob Storage API を使用するクライアントから、Blob Storage REST API を介して直接、または Azure Storage クライアント ライブラリから送信できます。 これらの要求には、トランザクションあたりの料金が発生します。 トランザクションの種類は、アカウントの課金方法に影響します。 たとえば、読み取りトランザクションは、書き込みトランザクションとは異なる課金カテゴリに発生します。 次の表に、ストレージ アカウントの種類に基づく Put Block List 要求の課金カテゴリを示します。
| Operation | ストレージ アカウントの種類 | 課金カテゴリ |
|---|---|---|
| ブロック リストを配置する | Premium ブロック BLOB 標準汎用 バージョン 2 標準汎用バージョン1 |
書き込み操作 |
指定された課金カテゴリの価格については、Azure Blob Storage の価格
こちらも参照ください
ブロックブロブ、追加ブロブ、ページブロブを理解する
Azure Storage への要求を承認する
状態とエラー コードの
ブロブサービスエラーコード
Blobサービス操作のタイムアウトを設定する