次の方法で共有

Put Block From URL

  • [アーティクル]

この操作により Put Block From URL 、URL から内容が読み取られる BLOB の一部としてコミットされる新しいブロックが作成されます。 この API は、バージョン 2018-03-28 以降で使用できます。

要求

要求は Put Block From URL 次のように構築できます。 HTTPS を使用することをお勧めします。 myaccount をストレージ アカウントの名前に置き換えます。

PUT メソッド要求 URI HTTP バージョン
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=block&blockid=id HTTP/1.1

エミュレートされたストレージ サービス要求

エミュレートされたストレージ サービスに対して要求を行うときは、エミュレーターのホスト名と BLOB サービス ポートを として 127.0.0.1:10000指定し、その後にエミュレートされたストレージ アカウント名を指定します。

PUT メソッド要求 URI HTTP バージョン
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=block&blockid=id HTTP/1.1

詳細については、ローカルでの Azure Storage の開発に Azurite エミュレーターを使用する方法に関するページを参照してください。

URI パラメーター

パラメーター 説明
blockid 必須。 ブロックを識別する有効な Base64 文字列値。 エンコードする前の文字列のサイズは 64 バイト以下である必要があります。

指定された BLOB の場合、パラメーターの指定された値 blockid の長さは、ブロックごとに同じサイズである必要があります。

注: Base64 文字列は URL エンコードされている必要があります。
timeout 省略可能。 timeout パラメーターは、秒単位で表されます。 詳細については、「 BLOB サービス操作のタイムアウトを設定する」を参照してください。

要求ヘッダー

必須の要求ヘッダーと省略可能な要求ヘッダーを次の表に示します。

要求ヘッダー 説明
Authorization 必須。 承認スキーム、アカウント名、署名を指定します。 詳細については、「Azure Storage への要求を承認する」をご覧ください。
Date または x-ms-date 必須。 要求に対して協定世界時 (UTC) を指定します。 詳細については、「Azure Storage への要求を承認する」をご覧ください。
x-ms-version すべての承認された要求に必要です。 この要求に使用する操作のバージョンを指定します。 詳細については、「Azure Storage サービスのバージョン管理」を参照してください。 の場合 Put Block From URL、バージョンは 2018-03-28 以降である必要があります。
Content-Length 必須。 要求本文で送信されるバイト数を指定します。 このヘッダーの値は 0 に設定する必要があります。 長さが 0 でない場合、状態コード 400 (Bad Request) で操作が失敗します。
x-ms-copy-source:name 必須。 ソース BLOB の URL を指定します。 値には、BLOB を指定する最大 2 kibibytes (KiB) の長さの URL を指定できます。 値は、要求 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 Storage への要求を承認する」をご覧ください。
Microsoft Entraではベアラー スキームのみがサポートされています。
このヘッダーは、バージョン 2020-10-02 以降でサポートされています。
x-ms-source-range 省略可能。 指定した範囲内のソース URL 内の BLOB のバイトのみをアップロードします。 このヘッダーが指定されていない場合、ソース BLOB の内容全体が 1 つのブロックとしてアップロードされます。 詳細については、「 BLOB サービス操作の範囲ヘッダーを指定する」を参照してください。
x-ms-source-content-md5 省略可能。 URI からのブロック コンテンツの MD5 ハッシュ。 このハッシュは、URI からのデータの転送中にブロックの整合性を確認するために使用されます。 このヘッダーを指定すると、ストレージ サービスはコピーソースから到着したコンテンツのハッシュをこのヘッダー値と比較します。

注: この MD5 ハッシュは BLOB と共に格納されません。

2 つのハッシュが一致しない場合、操作はエラー コード 400 (無効な要求) で失敗します。
x-ms-source-content-crc64 省略可能。 URI からのブロック コンテンツの CRC64 ハッシュ。 このハッシュは、URI からのデータの転送中にブロックの整合性を確認するために使用されます。 このヘッダーを指定すると、ストレージ サービスはコピーソースから到着したコンテンツのハッシュをこのヘッダー値と比較します。

注: この CRC64 ハッシュは BLOB と共に格納されません。

2 つのハッシュが一致しない場合、操作はエラー コード 400 (無効な要求) で失敗します。

ヘッダーと x-ms-source-content-crc64 ヘッダーの両方x-ms-source-content-md5が存在する場合、要求は 400 (無効な要求) で失敗します。

このヘッダーは、バージョン 2019-02-02 以降でサポートされています。
x-ms-encryption-scope 省略可能。 ソース コンテンツの暗号化に使用する暗号化スコープを示します。 このヘッダーは、バージョン 2019-02-02 以降でサポートされています。
x-ms-lease-id:<ID> BLOB にアクティブなリースが存在する場合は必須です。 アクティブなリースが存在する BLOB に対してこの操作を実行するには、このヘッダーに有効なリース ID を指定します。
x-ms-client-request-id 省略可能。 ログ記録の構成時にログに記録される 1 kibibyte (KiB) 文字制限を使用して、クライアントによって生成された不透明な値を提供します。 このヘッダーを使用して、クライアント側のアクティビティとサーバーが受信する要求を関連付けるよう強くお勧めします。 詳細については、「Azure Blob Storageの監視」を参照してください。

要求ヘッダー (顧客が指定した暗号化キー)

バージョン 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=block&blockid=AAAAAA%3D%3D HTTP/1.1  
  
Request Headers:  
x-ms-version: 2018-03-28  
x-ms-date: Sat, 31 Mar 2018 14:37:35 GMT    
Authorization: SharedKey myaccount:J4ma1VuFnlJ7yfk/Gu1GxzbfdJloYmBPWlfhZ/xn7GI=  
Content-Length: 0
x-ms-copy-source: https://myaccount.blob.core.windows.net/mycontainer/myblob
x-ms-source-range: bytes=0-499

Response

応答には、HTTP 状態コードおよび一連の応答ヘッダーが含まれています。

status code

操作が正常に終了すると、状態コード 201 (Created) が返されます。

状態コードの詳細については、「 状態とエラー コード」を参照してください。

応答ヘッダー

この操作の応答には、次のヘッダーが含まれています。 応答に追加の標準 HTTP ヘッダーが含まれる場合もあります。 すべての標準ヘッダーは 、HTTP/1.1 プロトコル仕様に準拠しています。

応答ヘッダー 説明
Content-MD5 クライアントがメッセージ コンテンツの整合性をチェックできるように返されます。 このヘッダーの値は、Blob Storage によって計算されます。 要求ヘッダーで指定された値と必ずしも同じとは限りません。 バージョン 2019-02-02 以降の場合、このヘッダーは要求にこのヘッダーがある場合にのみ返されます。
x-ms-content-crc64 バージョン 2019-02-02 以降の場合。 クライアントがメッセージ コンテンツの整合性をチェックできるように返されます。 このヘッダーの値は、Blob Storage によって計算されます。 これは、要求ヘッダーで指定された値と必ずしも同じとは限りません。

ヘッダーが要求に存在しない場合 x-ms-source-content-md5 に返されます。
x-ms-request-id 行われた要求を一意に識別し、それを使用して要求のトラブルシューティングを行うことができます。 詳細については、「 API 操作のトラブルシューティング」を参照してください。
x-ms-version 要求の実行に使用された Blob Storage のバージョン。
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:  
Transfer-Encoding: chunked  
x-ms-content-crc64: 77uWZTolTHU  
Date: Sat, 31 Mar 2018 23:47:09 GMT  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

承認

Azure Storage でデータ アクセス操作を呼び出す場合は、承認が必要です。 操作は、以下で Put Block From URL 説明するように承認できます。

重要

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 service に対する要求を認可するために使用できます。

Microsoft Entra IDを使用した承認の詳細については、「Microsoft Entra IDを使用して BLOB へのアクセスを承認する」を参照してください。

アクセス許可

Microsoft Entraユーザー、グループ、マネージド ID、またはサービス プリンシパルが操作を呼び出Put Block From URLすために必要な RBAC アクションと、このアクションを含む最小特権の組み込み Azure RBAC ロールを次に示します。

Azure RBAC を使用したロールの割り当ての詳細については、「 BLOB データにアクセスするための Azure ロールの割り当て」を参照してください。

注釈

Put Block From URL は、今後含めるブロックをブロック BLOB にアップロードします。 ブロック BLOB には、最大 50,000 個のブロックを含めることができます。 各ブロックは異なるサイズにすることができます。 でアップロードされる Put Block From URL ブロックの最大サイズは 100 メビバイト (MiB) です。 より大きなブロック (最大 4,000 MiB) をアップロードするには、「 ブロックの配置」を参照してください。

バージョン 2020-10-02 以降では、コピー操作のソースに対してMicrosoft Entra承認がサポートされています。

BLOB は、いつでも最大 100,000 個のコミットされていないブロックを持つことができます。 この最大値を超えた場合、サービスは状態コード 409 (RequestEntityTooLargeBlockCountExceedsLimit) を返します。

次の表では、許可されるブロックと BLOB の最大サイズをサービス のバージョン別に示します。

サービスのバージョン 最大ブロック サイズ (経由 Put Block From URL) 最大 BLOB サイズ (経由 Put Block List) 1 回の書き込み操作による最大 BLOB サイズ (経由 Put Blob From URL)
バージョン 2020-04-08 以降 4,000 MiB 約 190.7 テビバイト (TiB) (4,000 MiB × 50,000 ブロック) 5,000 MiB
2020-04-08 より前のバージョン 100 MiB 約 4.75 TiB (100 MiB × 50,000 ブロック) 256 MiB

一連のブロックをアップロードしたら、 Put Block List 操作を呼び出すことで、このセットからサーバー上の BLOB を作成または更新できます。 セット内の各ブロックは、その BLOB 内で一意のブロック ID によって識別されます。 ブロック ID のスコープは特定の BLOB に限定されているため、異なる BLOB に同じ ID のブロックが存在する場合があります。

まだ存在しない BLOB で を呼び出 Put Block From URL すと、コンテンツの長さが 0 の新しいブロック BLOB が作成されます。 この BLOB は、include=uncommittedblobs オプションを指定して List Blobs 操作を実行すると列挙されます。 新規 BLOB に対して Put Block List を呼び出すまで、アップロードしたブロックはコミットされません。 この方法で作成された BLOB は、サーバー上で 1 週間保持されます。 その期間内にブロックまたはコミットされたブロックを BLOB に追加していない場合、BLOB はガベージ コレクションされます。

操作で Put Block From URL 正常にアップロードされたブロックは、 でコミット Put Block Listされるまで BLOB の一部になりません。 を呼び出して新しい BLOB または更新された BLOB をコミットする前 Put Block List に、 Get Blob を呼び出す場合は、コミットされていないブロックを含めずに BLOB の内容が返されます。

まだコミットされていない別のブロックと同じブロック ID を持つブロックをアップロードした場合、その ID を持つ最後にアップロードされたブロックは、次に成功した Put Block List 操作でコミットされます。

Put Block List を呼び出すと、ブロック一覧に指定されたすべてのコミット前のブロックが新規 BLOB の一部としてコミットされます。 BLOB のブロック リストで指定されていないコミットされていないブロックは、ガベージ コレクションされ、Blob Storage から削除されます。 最後に成功Put Block From URLした操作の後、1 週間以内に同じ BLOB への呼び出しまたはPut Block List同じ BLOB に対するPut Block From URL呼び出しが成功しなかった場合は、コミットされていないブロックもガベージ コレクションされます。 PUT BLOB が BLOB で呼び出されると、コミットされていないブロックはすべてガベージ コレクションされます。

BLOB にアクティブなリースがある場合、クライアントは要求で有効なリース ID を指定して、ブロックを BLOB に書き込む必要があります。 クライアントでリース ID が指定されていないか、無効なリース ID が指定されている場合、Blob Storage は状態コード 412 (前提条件に失敗しました) を返します。 クライアントでリース ID が指定されているが、BLOB にアクティブなリースがない場合、Blob Storage は状態コード 412 (前提条件に失敗) も返します。

指定された BLOB の場合、すべてのブロック ID は同じ長さである必要があります。 既存のコミットされていないブロックのブロック ID とは異なる長さのブロック ID でブロックがアップロードされた場合、サービスはエラー応答コード 400 (Bad Request) を返します。

を呼び出 Put Block From URL しても、既存の BLOB の最終変更時刻は更新されません。

ページ BLOB に対して Put Block From URL を呼び出すと、エラーが返されます。

"アーカイブ" BLOB で を呼び出Put Block From URLすとエラーが返され、 または cool BLOB でhot呼び出しても BLOB 層は変更されません。

請求

価格要求は、Blob Storage REST API を介して直接、または Azure Storage クライアント ライブラリを介して Blob Storage API を使用するクライアントから送信できます。 これらの要求では、トランザクションあたりの料金が発生します。 トランザクションの種類は、アカウントの課金方法に影響します。 たとえば、読み取りトランザクションは、書き込みトランザクションとは異なる課金カテゴリに計上されます。 次の表は、ストレージ アカウントの種類に基づく要求の課金カテゴリ Put Block From URL を示しています。

操作 ストレージ アカウントの種類 課金カテゴリ
PUT Block From URL (宛先アカウント1) Premium ブロック BLOB
Standard 汎用 v2
Standard 汎用 v1		 書き込み操作
URL からブロックする (ソース アカウント2) Premium ブロック BLOB
Standard 汎用 v2
Standard 汎用 v1		 操作を読み取ります。

1宛先アカウントは、書き込みを開始するために 1 つのトランザクションに対して課金されます。
2ソース アカウントでは、ソース オブジェクトに対する読み取り要求ごとに 1 つのトランザクションが発生します。

さらに、送信元アカウントと移行先アカウントが異なるリージョン (米国北部や米国南部など) に存在する場合、要求の転送に使用される帯域幅は、エグレスとしてソース ストレージ アカウントに課金されます。 同じ地域内のアカウント間の送信は無料です。

指定した課金カテゴリの価格については、「Azure Blob Storage価格」を参照してください。

こちらもご覧ください