次の方法で共有

Put Page

  • [アーティクル]

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 Storage の開発に Azurite エミュレーターを使用する方法に関するページを参照してください。

URI パラメーター

次の追加パラメーターを要求 URI に指定できます。

パラメーター 説明
timeout 省略可能。 timeout パラメーターは、秒単位で表されます。 詳細については、「 BLOB サービス操作のタイムアウトを設定する」を参照してください。

要求ヘッダー

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

要求ヘッダー 説明
Authorization 必須。 承認スキーム、アカウント名、署名を指定します。 詳細については、「Azure Storage への要求を承認する」をご覧ください。
Date または x-ms-date 必須。 要求に対して協定世界時 (UTC) を指定します。 詳細については、「Azure Storage への要求を承認する」をご覧ください。
x-ms-version すべての承認された要求に必要です。 この要求に使用する操作のバージョンを指定します。 詳細については、「Azure Storage サービスのバージョン管理」を参照してください。
Range Range または x-ms-range が必須です。

ページとして書き込むバイト範囲を指定します。 範囲の開始値と終了値の両方を指定する必要があります。 このヘッダーは、 HTTP/1.1 プロトコル仕様によって定義されます。

ページ更新操作の場合、ページ範囲は最大 4 MiB です。 ページクリア操作の場合、ページ範囲は BLOB のフル サイズの値と同じくらい優れた値にすることができます。

ページは 512 バイトの境界に揃える必要があるため、開始オフセットは 512 の剰余で、終了オフセットは 512 –1 の剰余である必要があります。 有効なバイト範囲の例としては、0 から 511、512 から 1023 などがあります。

Blob Storage はヘッダーに対Rangeして 1 バイト範囲のみを受け入れ、バイト範囲は 次の形式で指定する必要があります。 bytes=startByte-endByte

Range と x-ms-range の両方が指定されている場合、サービスは x-ms-range の値を使用します。 詳細については、「 BLOB サービス操作の範囲ヘッダーを指定する」を参照してください。
x-ms-range Range または x-ms-range が必須です。

ページとして書き込むバイト範囲を指定します。 範囲の開始値と終了値の両方を指定する必要があります。 このヘッダーは、 HTTP/1.1 プロトコル仕様によって定義されます。

ページ更新操作の場合、ページ範囲のサイズは 4 MiB と同じになります。 ページのクリア操作では、ページ範囲の最大サイズは BLOB 全体のサイズの値です。

ページは 512 バイトの境界に揃える必要があるため、開始オフセットは 512 の剰余で、終了オフセットは 512 から 1 の剰余である必要があります。 有効なバイト範囲は、たとえば 0 ～ 511、512 ～ 1023 のようになります。

Blob Storage はヘッダーに対x-ms-rangeして 1 バイト範囲のみを受け入れ、バイト範囲は 次の形式で指定する必要があります。 bytes=startByte-endByte

Range と x-ms-range の両方が指定されている場合、サービスは x-ms-range の値を使用します。 詳細については、「 BLOB サービス操作の範囲ヘッダーを指定 する」を参照してください。
Content-Length 必須。 要求本文で送信されるバイト数を指定します。 ヘッダーが x-ms-page-write に clear設定されている場合、このヘッダーの値を に設定する 0必要があります。
Content-MD5 省略可能。 ページのコンテンツの MD5 ハッシュ。 このハッシュは転送時のページの整合性を確認するために使用します。 このヘッダーを指定すると、ストレージ サービスによって、到達したコンテンツのハッシュと、このヘッダー値が比較されます。
<br / >Note: この MD5 ハッシュは BLOB と共に格納されません。

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

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

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

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

このヘッダーは、バージョン 2019-02-02 以降でサポートされています。
x-ms-page-write: {update ¦ clear} 必須。 次のいずれかのオプションを指定することができます。

- Update: 要求本文で指定されたバイトを指定された範囲に書き込みます。 更新を実行するには、Range ヘッダーと Content-Length ヘッダーが一致している必要があります。
- Clear: 指定した範囲をクリアし、その範囲のストレージで使用されている領域を解放します。 範囲をクリアするには、ヘッダーを Content-Length に 0設定し、ヘッダーを Range クリアする範囲を示す値 (最大 BLOB サイズまで) に設定します。
x-ms-encryption-scope 省略可能。 要求の内容を暗号化するために使用する暗号化スコープを示します。 このヘッダーは、バージョン 2019-02-02 以降でサポートされています。
x-ms-lease-id:<ID> BLOB にアクティブなリースが存在する場合は必須です。 アクティブなリースが存在する BLOB に対してこの操作を実行するには、このヘッダーに有効なリース ID を指定します。
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 Storage は状態コード 412 (前提条件に失敗しました) を返します。
If-Unmodified-Since 省略可能。 DateTime 値。 指定した日付/時刻以降に BLOB が変更されていない場合にのみ、この条件付きヘッダーを指定してページを書き込みます。 BLOB が変更された場合、Blob Storage は状態コード 412 (前提条件に失敗) を返します。
If-Match 省略可能。 ETag 値。 この条件ヘッダーの ETag 値を指定すると、BLOB の ETag 値が指定した値に一致する場合にのみページが書き込まれます。 値が一致しない場合、Blob Storage は状態コード 412 (前提条件に失敗しました) を返します。
If-None-Match 省略可能。 ETag 値。

BLOB の ETag 値が指定された値と一致しない場合にのみ、この条件付きヘッダーに ETag 値を指定してページを書き込みます。 値が同じ場合、Blob Storage は状態コード 412 (前提条件失敗) を返します。
x-ms-client-request-id 省略可能。 ログ記録の構成時にログに記録される 1 kibibyte (KiB) 文字制限を使用して、クライアントによって生成された不透明な値を提供します。 このヘッダーを使用して、クライアント側のアクティビティとサーバーが受信する要求を関連付けるよう強くお勧めします。 詳細については、「Azure Blob Storageの監視」を参照してください。

この操作では、条件ヘッダーを使用して、指定した条件を満たした場合にのみ操作を実行することもできます。 詳細については、「 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=

Response

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

status code

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

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

応答ヘッダー

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

構文 説明
ETag BLOB の ETag。 要求バージョンが 2011-08-18 以降の場合、ETag 値は引用符で囲まれます。 If-Match 要求ヘッダーまたは If-None-Match 要求ヘッダーに ETag の値を指定すると、条件付き Put Page 操作を実行できます。
Last-Modified BLOB が最後に変更された日時。 日付形式は RFC 1123 に従います。 詳細については、「 ヘッダーの日付/時刻値を表す」を参照してください。

BLOB の書き込み操作 (BLOB のメタデータまたはプロパティの更新など) を行うと、BLOB の最終更新時刻が変更されます。
Content-MD5 このヘッダーは、クライアントがメッセージ内容の整合性を確認する目的で返されます。 このヘッダーの値は、Blob Storage によって計算されます。 要求ヘッダーで指定された値と必ずしも同じとは限りません。 バージョン 2019-02-02 以降の場合、このヘッダーは要求にこのヘッダーがある場合にのみ返されます。
x-ms-content-crc64 バージョン 2019-02-02 以降では、クライアントがメッセージ コンテンツの整合性をチェックできるように、このヘッダーが返されます。 このヘッダーの値は、Blob Storage によって計算されます。 要求ヘッダーで指定された値と必ずしも同じとは限りません。

ヘッダーが要求に存在しない場合 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 Storage でデータ アクセス操作を呼び出す場合は、承認が必要です。 操作は、以下で Put Page 説明するように承認できます。

重要

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 Pageすために必要な RBAC アクションと、このアクションを含む最小特権の組み込み Azure RBAC ロールを次に示します。

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

注釈

Put Page 操作は、ページ BLOB にページ範囲を書き込みます。 この操作は、既存のページ BLOB でのみ呼び出すことができます。 新しいページ BLOB を作成するために呼び出したり、ブロック BLOB で呼び出したりすることはできません。 現在存在しない BLOB 名で を呼び出すと Put Page 、HTTP 状態コード 404 (見つかりません) が返されます。

新しいページ BLOB を作成するには、 Put Blob を 呼び出し、作成する BLOB の種類をページ BLOB として指定します。 ページ BLOB のサイズは最大 8 TiB です。

BLOB にアクティブなリースがある場合、クライアントはページを書き込む要求に対して有効なリース ID を指定する必要があります。

ページ更新操作

Update オプションを指定して Put Page を呼び出すと、指定したページ BLOB に対してインプレース書き込みが実行されます。 指定したページのコンテンツが更新で上書きされます。

重要

サーバーがタイムアウトした場合、または操作中に Put Page 接続が閉じている場合、ページが更新された可能性があります。 そのため、成功を示す応答を受け取るまで、更新を再試行し続ける必要があります。

更新操作に対して で送信される Put Page ページの各範囲のサイズは、最大 4 MiB です。 ページ範囲の開始値と終了値は、512 バイトの境界に合わせて指定する必要があります。 4 MiB を超えるページの範囲をアップロードしようとすると、サービスは状態コード 413 (要求エンティティが大きすぎる) を返します。

ページクリア操作

オプションを指定して をClear呼び出すとPut Page、指定したページで使用される記憶域が解放されます。 クリアされたページは、ページ BLOB の一部として追跡されなくなります。

消去されたページでは、ストレージ リソースが解放されているため、ストレージ アカウントに対する料金は発生しなくなりました。 唯一の例外は、ページ BLOB の既存のスナップショットがある場合です。 スナップショット内のページは、ソース BLOB の一部として同じページが存在しなくなった場合に課金されます。

コンカレンシーの問題を管理する

Blob Storage は、重複するページへの同時書き込みを順番に処理します。 つまり、サービスによって最後に処理されたページによって、BLOB のコンテンツが決まります。 したがって、BLOB のコンテンツの整合性を確保するために、クライアントは、次の 1 つ以上の方法を使用して、重複するページへの書き込みを処理する必要があります。

  • Put Page の呼び出しが成功するたびに、Last-Modified 応答ヘッダーの値を確認します。 Blob Storage から返される応答の順序は、サービスによって実行された順序と必ずしも一致するとは限りません。 しかし、Last-Modified の値は常に、サービスが要求を処理した順序を示します。

  • オプティミスティック コンカレンシー制御を使用して、BLOB の ETag または最終更新時刻に基づく条件付き更新を実行します。 この方法は、同時書き込みの数が比較的少ない場合にうまく機能します。 この目的には、If-Match、If-None-Match、If-Modified-Since、および If-Unmodified-Since の各条件要求ヘッダーを使用します。

  • リース BLOB を呼び出して、1 分間、またはリースが更新された場合はそれ以上の間、他の書き込みに対して BLOB をロックできます。

  • BLOB のシーケンス番号を使用して、応答がなかった要求を再試行しても同時更新が発生しないようにすることができます。 この方法は、ページ書き込みに高いスループットを必要とするクライアントに最適な場合があります。 これについては、次のセクションで詳しく説明します。

ページ BLOB シーケンス番号を使用して要求を再試行する

への Put Page 呼び出しがタイムアウトするか、応答を返さない場合、要求が成功したかどうかを特定する方法はありません。 そのため、要求を再試行する必要がありますが、Azure Storage サービスの分散された性質により、再試行された要求が成功した後に元の要求が処理される可能性があります。 遅れて処理された元の要求によって他の更新が上書きされ、予期しない結果が生じることがあります。 次のシーケンスは、このような状況を示しています。

  1. Put Pageページ 0 に値 "X" を書き込む要求がタイムアウトするか、応答を返しません。

  2. 値 "X" をページ 0 に書き込む要求の再試行が成功する。

  3. 値 "Y" をページ 0 に書き込む要求が成功する。

  4. 元の要求が成功し、値 "X" がページ 0 に書き込まれる。

  5. ページ 0 の読み取りで、クライアントがこの時点で予期した値 "Y" ではなく値 "X" が返される。

この種の競合は、元の要求が 100 から 499、または 503 (サーバービジー) の状態コードを返さない場合に発生する可能性があります。 これらのステータス コードのいずれかが返された場合は、要求が成功したか失敗したかを確実に知ることができます。 しかし、サービスがこの範囲外のステータス コードを返した場合は、元の要求の状態を知ることはできません。

この種の競合を防ぐために、ページ BLOB のシーケンス番号を使用して、要求を再試行したときに元の要求が成功しないようにすることができます。 これを行うには、元の要求を再試行する前にシーケンス番号を増やす必要があります。 その後、条件付きシーケンス番号ヘッダーを使用して、シーケンス番号が予想されるシーケンス番号と一致しない場合に要求が失敗することを確認できます。 この方法は次のような順序で行われます。

  1. クライアントは Put BLOB を使用してページ BLOB を 作成し、そのシーケンス番号を に 0設定します。

  2. Put Pageヘッダーがタイムアウトに設定されているか、応答が返されないページ 0 if-sequence-number-lt に値 "X" を1書き込む要求。

  3. クライアントは を呼び出 Set Blob Properties してシーケンス番号を に 1更新します。

  4. 値 "X" をページ 0 に書き込む再試行された要求で if-sequence-number-lt 、 が成功に 2 設定されています。

  5. 成功に設定2されたページ 0 if-sequence-number-lt に値 "Y" を書き込む要求。

  6. 元の要求は最終的に処理されますが、シーケンス番号を 1 未満にする必要がある条件 (つまり、ヘッダーが に1設定されている) を指定するため、if-sequence-num-lt失敗します。 エラーは SequenceNumberConditionNotMet (HTTP ステータス コード 412 – Precondition Failed)。

  7. ページ 0 の読み取りで、予期した値 "Y" が返される。

こちらもご覧ください

Azure Storage への要求を承認する
状態コードとエラー コード
BLOB サービス操作のタイムアウトを設定する