Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Operasi ini Put Page From URL
menulis rentang halaman ke blob halaman tempat konten dibaca dari URL. API ini tersedia mulai versi 09-11-2018.
Permohonan
Anda dapat membuat permintaan Put Page From URL
sebagai berikut. Kami menyarankan agar Anda menggunakan HTTPS. Ganti myaccount dengan nama akun penyimpanan Anda:
URI permintaan metode PUT | Versi HTTP |
---|---|
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=page |
HTTP/1.1 |
URI Layanan Penyimpanan yang Diemulasikan
Saat Anda membuat permintaan terhadap layanan penyimpanan yang diemulasi, tentukan nama host emulator dan port layanan Blob sebagai 127.0.0.1:10000
, diikuti dengan nama akun penyimpanan yang diemulasi:
URI permintaan metode PUT | Versi HTTP |
---|---|
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=page |
HTTP/1.1 |
Untuk informasi selengkapnya, lihat Menggunakan emulator Azurite untuk pengembangan Azure Storage lokal.
URI Parameter
Anda dapat menentukan parameter tambahan berikut pada URI permintaan:
Pengaturan | Deskripsi |
---|---|
timeout |
Fakultatif. Parameter timeout dinyatakan dalam hitung detik. Untuk informasi selengkapnya, lihat Mengatur batas waktu untuk operasi blob service. |
Tajuk permintaan
Header permintaan yang diperlukan dan opsional dijelaskan dalam tabel berikut:
Tajuk permintaan | Deskripsi |
---|---|
Authorization |
Dibutuhkan. Menentukan skema otorisasi, nama akun, dan tanda tangan. Untuk informasi selengkapnya, lihat Mengotorisasi permintaan ke Azure Storage. |
Date atau x-ms-date |
Dibutuhkan. Menentukan Waktu Universal Terkoordinasi (UTC) untuk permintaan tersebut. Untuk informasi selengkapnya, lihat Mengotorisasi permintaan ke Azure Storage. |
x-ms-version |
Diperlukan untuk semua permintaan yang diotorisasi. Menentukan versi operasi yang akan digunakan untuk permintaan ini. Untuk informasi selengkapnya, lihat Penerapan Versi untuk layanan Azure Storage. |
Range |
Baik Range atau x-ms-range diperlukan.Menentukan rentang byte yang akan ditulis sebagai halaman. Mulai dan akhir rentang harus ditentukan. Header ini ditentukan oleh spesifikasi protokol HTTP/1.1 . Untuk operasi pembaruan halaman, rentang halaman dapat berukuran hingga 4 MiB. Karena halaman harus disejajarkan dengan batas 512 byte, offset awal harus berupa modulus 512 dan offset akhir harus modulus 512 – 1. Contoh rentang byte yang valid adalah 0-511, 512-1023, dan seterusnya. Layanan Blob hanya menerima rentang byte tunggal untuk Range header, dan rentang byte harus ditentukan dalam format berikut: bytes=startByte-endByte .Jika Range dan x-ms-range ditentukan, layanan menggunakan nilai x-ms-range . Untuk informasi selengkapnya, lihat Menentukan header rentang untuk operasi layanan Blob. |
x-ms-range |
Baik Range atau x-ms-range diperlukan.Menentukan rentang byte yang akan ditulis sebagai halaman. Mulai dan akhir rentang harus ditentukan. Header ini ditentukan oleh spesifikasi protokol HTTP/1.1 . Rentang halaman dapat berukuran hingga 4 MiB. Karena halaman harus disejajarkan dengan batas 512 byte, offset awal harus berupa modulus 512 dan offset akhir harus modulus 512 – 1. Contoh rentang byte yang valid adalah 0-511, 512-1023, dan seterusnya. Layanan Blob hanya menerima rentang byte tunggal untuk x-ms-range header, dan rentang byte harus ditentukan dalam format berikut: bytes=startByte-endByte .Jika Range dan x-ms-range ditentukan, layanan menggunakan nilai x-ms-range . Untuk informasi selengkapnya, lihat Menentukan header rentang untuk operasi layanan Blob. |
Content-Length |
Dibutuhkan. Menentukan jumlah byte yang ditransmisikan dalam isi permintaan. Nilai header ini harus diatur ke nol. Ketika panjangnya tidak nol, operasi gagal dengan kode status 400 (Permintaan Buruk). |
x-ms-copy-source:name |
Dibutuhkan. Menentukan URL blob sumber. Nilainya dapat berupa URL dengan panjang hingga 2 KiB yang menentukan blob. Nilai harus dikodekan URL karena akan muncul dalam URI permintaan. Blob sumber harus bersifat publik atau harus diizinkan melalui tanda tangan akses bersama. Jika blob sumber bersifat publik, tidak diperlukan otorisasi untuk melakukan operasi. Berikut adalah beberapa contoh URL objek sumber: - 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> |
Fakultatif. Menentukan skema otorisasi dan tanda tangan untuk sumber salinan. Untuk informasi selengkapnya, lihat Mengotorisasi permintaan ke Azure Storage. Hanya pembawa skema yang didukung untuk Microsoft Entra. Header ini didukung dalam versi 2020-10-02 dan yang lebih baru. |
x-ms-source-range |
Mengunggah byte blob di URL sumber dalam rentang yang ditentukan. Mulai dan akhir rentang harus ditentukan. Header ini ditentukan oleh spesifikasi protokol HTTP/1.1 . Rentang halaman dapat berukuran hingga 4 MiB. Layanan Blob hanya menerima rentang byte tunggal untuk x-ms-source-range header, dan rentang byte harus ditentukan dalam format berikut: bytes=startByte-endByte .Lihat Menentukan header rentang untuk operasi layanan Blob untuk informasi selengkapnya. |
x-ms-source-content-md5 |
Fakultatif. Hash MD5 dari konten halaman dari URI. Hash ini digunakan untuk memverifikasi integritas halaman selama pengangkutan data dari URI. Saat header ini ditentukan, layanan penyimpanan membandingkan hash konten yang telah tiba dari sumber salinan dengan nilai header ini. Catatan: Hash MD5 ini tidak disimpan dengan blob. Jika kedua hash tidak cocok, operasi gagal dengan kode kesalahan 400 (Permintaan Buruk). |
x-ms-source-content-crc64 |
Fakultatif. Hash CRC64 dari konten halaman dari URI. Hash ini digunakan untuk memverifikasi integritas halaman selama pengangkutan data dari URI. Saat header ini ditentukan, layanan penyimpanan membandingkan hash konten yang telah tiba dari sumber salinan dengan nilai header ini. Catatan: Hash CRC64 ini tidak disimpan dengan blob. Jika kedua hash tidak cocok, operasi gagal dengan kode kesalahan 400 (Permintaan Buruk). Jika keduanya x-ms-source-content-md5 dan x-ms-source-content-crc64 header ada, permintaan gagal dengan 400 (Permintaan Buruk).Header ini didukung dalam versi 2019-02-02 dan yang lebih baru. |
x-ms-lease-id:<ID> |
Diperlukan jika blob memiliki sewa aktif. Untuk melakukan operasi ini pada blob dengan sewa aktif, tentukan ID sewa yang valid untuk header ini. |
x-ms-if-sequence-number-le: <num> |
Fakultatif. Jika nomor urutan blob kurang dari atau sama dengan nilai yang ditentukan, permintaan dilanjutkan. Jika tidak, itu gagal dengan kesalahan SequenceNumberConditionNotMet (kode status HTTP 412 – Prasyarat Gagal). |
x-ms-if-sequence-number-lt: <num> |
Fakultatif. Jika nomor urut blob kurang dari nilai yang ditentukan, permintaan dilanjutkan. Jika tidak, itu gagal dengan kesalahan SequenceNumberConditionNotMet (kode status HTTP 412 – Prakondisi Gagal). |
x-ms-if-sequence-number-eq: <num> |
Fakultatif. Jika nomor urut blob sama dengan nilai yang ditentukan, permintaan dilanjutkan. Jika tidak, itu gagal dengan kesalahan SequenceNumberConditionNotMet (kode status HTTP 412 – Prakondisi Gagal). |
If-Modified-Since |
Fakultatif. Nilai DateTime . Tentukan header bersyarat ini untuk menulis halaman hanya jika blob telah dimodifikasi sejak tanggal/waktu yang ditentukan. Jika blob belum dimodifikasi, layanan Blob mengembalikan kode status 412 (Prasyarat Gagal). |
If-Unmodified-Since |
Fakultatif. Nilai DateTime . Tentukan header bersyarat ini untuk menulis halaman hanya jika blob belum dimodifikasi sejak tanggal/waktu yang ditentukan. Jika blob telah dimodifikasi, layanan Blob mengembalikan kode status 412 (Prasyarat Gagal). |
If-Match |
Fakultatif. Nilai ETag. Tentukan nilai ETag untuk header bersyarat ini untuk menulis halaman hanya jika nilai ETag blob cocok dengan nilai yang ditentukan. Jika nilainya tidak cocok, layanan Blob mengembalikan kode status 412 (Prasyarat Gagal). |
If-None-Match |
Fakultatif. Nilai ETag. Tentukan nilai ETag untuk header bersyarat ini untuk menulis halaman hanya jika nilai ETag blob tidak cocok dengan nilai yang ditentukan. Jika nilainya identik, layanan Blob mengembalikan kode status 412 (Prasyarat Gagal). |
x-ms-encryption-scope |
Fakultatif. Menunjukkan cakupan enkripsi yang akan digunakan untuk mengenkripsi konten sumber. Header ini didukung dalam versi 2019-02-02 dan yang lebih baru. |
x-ms-client-request-id |
Fakultatif. Menyediakan nilai buram yang dihasilkan klien dengan batas karakter 1 kibibyte (KiB) yang dicatat dalam log saat pengelogan dikonfigurasi. Kami sangat menyarankan Anda menggunakan header ini untuk menghubungkan aktivitas sisi klien dengan permintaan yang diterima server. Untuk informasi selengkapnya, lihat Memantau Azure Blob Storage. |
x-ms-file-request-intent |
Diperlukan jika x-ms-copy-source header adalah URL file Azure dan x-ms-copy-source-authorization header menentukan token OAuth. Nilai yang dapat diterima backup . Header ini menentukan bahwa Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action atau Microsoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/action harus diberikan jika disertakan dalam kebijakan RBAC yang ditetapkan ke identitas yang diotorisasi menggunakan header x-ms-copy-source-authorization . Tersedia untuk versi 2025-07-05 dan yang lebih baru. |
Operasi ini juga mendukung penggunaan header bersyarah untuk menjalankan operasi hanya jika kondisi tertentu terpenuhi. Untuk informasi selengkapnya, lihat Menentukan header kondisional untuk operasi blob service.
Header permintaan (kunci enkripsi yang disediakan pelanggan)
Pada versi 2019-02-02, header berikut dapat ditentukan pada permintaan untuk mengenkripsi blob yang dienkripsi dengan kunci yang disediakan pelanggan. Enkripsi dengan kunci yang disediakan pelanggan (dan kumpulan header yang sesuai) bersifat opsional.
Tajuk permintaan | Deskripsi |
---|---|
x-ms-encryption-key |
Dibutuhkan. Kunci enkripsi AES-256 yang dikodekan Base64. |
x-ms-encryption-key-sha256 |
Dibutuhkan. Hash SHA256 yang dikodekan Base64 dari kunci enkripsi. |
x-ms-encryption-algorithm: AES256 |
Dibutuhkan. Menentukan algoritma yang akan digunakan untuk enkripsi. Nilai header ini harus AES256 . |
Isi dari permintaan
Isi permintaan berisi konten halaman.
Permohonan sampel
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
Jawaban
Respons mencakup kode status HTTP dan sekumpulan header respons.
Kode status
Operasi yang berhasil mengembalikan kode status 201 (Dibuat).
Untuk informasi selengkapnya tentang kode status, lihat Status dan kode kesalahan.
Tajuk respons
Respons untuk operasi ini mencakup header berikut. Respons juga dapat mencakup header HTTP standar tambahan. Semua header standar sesuai dengan spesifikasi protokol HTTP/1.1 .
Sintaksis | Deskripsi |
---|---|
ETag |
ETag untuk gumpalan. Jika versi permintaan adalah 2011-08-18 dan yang lebih baru, nilai ETag diapit dalam tanda kutip. ETag dapat digunakan untuk melakukan operasi bersyarat Put Page From URL dengan menentukan nilainya untuk If-Match header atau If-None-Match permintaan. |
Last-Modified |
Tanggal dan waktu blob terakhir diubah. Format tanggal mengikuti RFC 1123. Untuk informasi selengkapnya, lihat Mewakili nilai tanggal/waktu di header. Setiap operasi tulis pada blob, termasuk pembaruan metadata atau properti blob, mengubah waktu modifikasi terakhir blob. |
Content-MD5 |
Dikembalikan sehingga klien dapat memeriksa integritas konten pesan. Nilai header ini dihitung oleh layanan Blob. Ini tidak selalu sama dengan nilai yang ditentukan dalam header permintaan. Untuk versi 2019-02-02 atau yang lebih baru, header ini hanya dikembalikan jika permintaan memiliki header ini. |
x-ms-content-crc64 |
Untuk versi 2019-02-02 atau yang lebih baru. Dikembalikan sehingga klien dapat memeriksa integritas konten pesan. Nilai header ini dihitung oleh layanan Blob. Ini tidak selalu sama dengan nilai yang ditentukan dalam header permintaan. Header ini dikembalikan saat x-ms-source-content-md5 header tidak ada dalam permintaan. |
x-ms-blob-sequence-number |
Nomor urutan saat ini untuk blob halaman. |
x-ms-request-id |
Mengidentifikasi permintaan yang dibuat secara unik, dan dapat digunakan untuk memecahkan masalah permintaan. Untuk informasi selengkapnya, lihat Memecahkan masalah operasi API. |
x-ms-version |
Menunjukkan versi blob service yang digunakan untuk menjalankan permintaan. Header ini dikembalikan untuk permintaan yang dibuat terhadap versi 2009-09-19 dan yang lebih baru. |
Date |
Nilai tanggal/waktu UTC yang dihasilkan oleh layanan, yang menunjukkan waktu ketika respons dimulai. |
x-ms-request-server-encrypted: true/false |
Versi 2015-12-11 dan yang lebih baru. Nilai header ini diatur ke true jika konten permintaan berhasil dienkripsi dengan menggunakan algoritme yang ditentukan, dan false sebaliknya. |
x-ms-encryption-key-sha256 |
Versi 2019-02-02 dan yang lebih baru. Dikembalikan jika permintaan menggunakan kunci yang disediakan pelanggan untuk enkripsi, sehingga klien dapat memastikan bahwa konten permintaan berhasil dienkripsi dengan menggunakan kunci yang disediakan. |
x-ms-encryption-scope |
Versi 2019-02-02 dan yang lebih baru. Dikembalikan jika permintaan menggunakan cakupan enkripsi, sehingga klien dapat memastikan bahwa konten permintaan berhasil dienkripsi dengan menggunakan cakupan enkripsi. |
x-ms-client-request-id |
Dapat digunakan untuk memecahkan masalah permintaan dan respons yang sesuai. Nilai header ini sama dengan nilai header x-ms-client-request-id jika ada dalam permintaan dan nilai berisi tidak lebih dari 1.024 karakter ASCII yang terlihat. Jika header x-ms-client-request-id tidak ada dalam permintaan, header tersebut tidak akan ada dalam respons. |
Badan respons
Tidak ada.
Contoh tanggapan
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
Otorisasi
Otorisasi diperlukan saat memanggil operasi akses data apa pun di Azure Storage. Anda dapat mengotorisasi operasi Put Page From URL
seperti yang dijelaskan di bawah ini.
Penting
Microsoft merekomendasikan penggunaan ID Microsoft Entra dengan identitas terkelola untuk mengotorisasi permintaan ke Azure Storage. MICROSOFT Entra ID menyediakan keamanan yang unggul dan kemudahan penggunaan dibandingkan dengan otorisasi Kunci Bersama.
- ID Microsoft Entra (disarankan)
-
tanda tangan akses bersama (SAS)
-
kunci bersama
Azure Storage mendukung penggunaan ID Microsoft Entra untuk mengotorisasi permintaan ke data blob. Dengan MICROSOFT Entra ID, Anda dapat menggunakan kontrol akses berbasis peran Azure (Azure RBAC) untuk memberikan izin kepada prinsip keamanan. Prinsip keamanan mungkin pengguna, grup, perwakilan layanan aplikasi, atau identitas terkelola Azure. Prinsip keamanan diautentikasi oleh MICROSOFT Entra ID untuk mengembalikan token OAuth 2.0. Token kemudian dapat digunakan untuk mengotorisasi permintaan terhadap layanan Blob.
Untuk mempelajari selengkapnya tentang otorisasi menggunakan ID Microsoft Entra, lihat Mengotorisasi akses ke blob menggunakan ID Microsoft Entra.
Hak akses
Tercantum di bawah ini adalah tindakan RBAC yang diperlukan untuk pengguna, grup, identitas terkelola, atau perwakilan layanan Microsoft Entra untuk memanggil operasi Put Page From URL
, dan peran Azure RBAC bawaan yang paling tidak istimewa yang mencakup tindakan ini:
- tindakan Azure RBAC:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Peran bawaan dengan hak istimewa paling sedikit: Kontributor Data Blob Penyimpanan
Untuk mempelajari selengkapnya tentang menetapkan peran menggunakan Azure RBAC, lihat Menetapkan peran Azure untuk akses ke data blob.
Komentar
Operasi ini Put Page From URL
menulis rentang halaman ke blob halaman. Operasi ini hanya dapat dipanggil pada blob halaman yang ada. Itu tidak dapat dipanggil untuk membuat blob halaman baru, juga tidak dapat dipanggil pada blob blok. Memanggil Put Page From URL
dengan nama blob yang saat ini tidak ada mengembalikan kesalahan BlobNotFound (kode status HTTP 404 – Tidak Ditemukan).
Dalam versi 2020-10-02 dan yang lebih baru, otorisasi Microsoft Entra didukung untuk sumber operasi salin.
Untuk membuat blob halaman baru, panggil Put Blob dan tentukan jenis blob yang akan dibuat sebagai blob halaman. Gumpalan halaman dapat berukuran hingga 8 TiB.
Jika blob memiliki sewa aktif, klien harus menentukan ID sewa yang valid pada permintaan untuk menulis halaman.
Operasi pembaruan halaman
Pemanggilan Put Page From URL
melakukan penulisan di tempat pada blob halaman yang ditentukan. Konten apa pun di halaman yang ditentukan akan ditimpa dengan pembaruan.
Penting
Jika waktu server habis atau koneksi Anda ditutup selama Put Page From URL
, halaman mungkin telah diperbarui atau tidak. Oleh karena itu, Anda harus terus mencoba pembaruan lagi hingga menerima respons yang menunjukkan keberhasilan.
Setiap rentang halaman yang dikirimkan untuk Put Page From URL
operasi pembaruan dapat berukuran hingga 4 MiB. Rentang awal dan akhir halaman harus disejajarkan dengan batas 512 byte. Jika Anda mencoba mengunggah rentang halaman yang lebih besar dari 4 MiB, layanan akan menampilkan kode status 413 (Entitas Permintaan Terlalu Besar).
Mengelola masalah konkurensi
Layanan Blob menangani penulisan bersamaan ke halaman yang tumpang tindih secara berurutan. Artinya, halaman terakhir yang diproses oleh layanan menentukan konten blob. Oleh karena itu, untuk memastikan integritas konten blob, klien harus menangani penulisan ke halaman yang tumpang tindih menggunakan satu atau beberapa pendekatan berikut:
Anda dapat memeriksa nilai
Last-Modified
header respons untuk setiap panggilan yang berhasil kePut Page From URL
. Urutan respons yang dikembalikan dari layanan Blob tidak selalu sesuai dengan urutan di mana respons tersebut dieksekusi oleh layanan. Tetapi nilai selaluLast-Modified
menunjukkan urutan di mana layanan memproses permintaan.Anda dapat melakukan pembaruan secara kondisional berdasarkan ETag blob atau waktu terakhir dimodifikasi menggunakan konkurensi optimis. Pendekatan ini bekerja dengan baik jika jumlah penulisan bersamaan relatif rendah. Gunakan header
If-Match
permintaan bersyarat ,If-None-Match
,If-Modified-Since
, danIf-Unmodified-Since
untuk tujuan ini.Anda dapat memanggil Lease Blob untuk mengunci blob terhadap penulisan lain untuk periode satu menit, atau lebih lama jika sewa diperpanjang.
Anda dapat menggunakan nomor urutan blob untuk memastikan bahwa mencoba kembali permintaan yang tidak ada responsnya tidak menghasilkan pembaruan bersamaan. Pendekatan ini mungkin yang terbaik untuk klien yang membutuhkan throughput tinggi untuk penulisan halaman. Ini dijelaskan secara rinci di bagian berikut.
Menggunakan nomor urutan blob halaman untuk mencoba kembali permintaan
Saat panggilan untuk Put Page From URL
waktu habis atau tidak mengembalikan tanggapan, tidak ada cara untuk mengetahui dengan pasti apakah permintaan berhasil. Oleh karena itu, Anda perlu mencoba kembali permintaan, tetapi karena sifat terdistribusi dari layanan penyimpanan Azure, permintaan asli dimungkinkan untuk diproses setelah permintaan yang dicoba ulang berhasil. Permintaan asli yang tertunda dapat menimpa pembaruan lain dan menghasilkan hasil yang tidak terduga. Urutan berikut menggambarkan bagaimana hal ini dapat terjadi:
Permintaan
Put Page From URL
untuk menulis nilai "X" ke halaman 0 habis atau tidak mengembalikan respons.Permintaan yang dicoba ulang untuk menulis nilai "X" ke halaman 0 berhasil.
Permintaan untuk menulis nilai "Y" ke halaman 0 berhasil.
Permintaan asli berhasil, menulis nilai "X" ke halaman 0.
Membaca halaman 0 mengembalikan nilai "X", ketika klien pada titik ini mengharapkan nilai "Y".
Konflik semacam ini dapat terjadi ketika permintaan asli tidak mengembalikan kode status antara 100-499, atau 503 (Server Sibuk). Jika salah satu kode status ini dikembalikan, Anda dapat yakin apakah permintaan telah berhasil atau gagal. Tetapi jika layanan mengembalikan kode status di luar rentang ini, tidak ada cara untuk mengetahui status permintaan asli.
Untuk mencegah konflik semacam ini, Anda dapat menggunakan nomor urutan blob halaman untuk memastikan bahwa saat Anda mencoba kembali permintaan, permintaan asli tidak akan berhasil selanjutnya. Untuk melakukannya, Anda harus menambah nomor urut sebelum mencoba kembali permintaan asli. Anda kemudian dapat menggunakan header nomor urut bersyarat untuk memastikan bahwa permintaan gagal jika nomor urutnya tidak cocok dengan nomor urut yang diharapkan. Urutan berikut mengilustrasikan pendekatan ini:
Klien membuat blob halaman dengan Put Blob dan mengatur nomor urutnya ke 0.
Permintaan
Put Page From URL
untuk menulis nilai "X" ke halaman 0 denganif-sequence-number-lt
header diatur ke1
waktu habis atau tidak mengembalikan respons.Klien memanggil Set Blob Properties untuk memperbarui nomor urut ke 1.
Permintaan yang dicoba ulang untuk menulis nilai "X" ke halaman 0 dengan
if-sequence-number-lt
set to2
berhasil.Permintaan untuk menulis nilai "Y" ke halaman 0 dengan
if-sequence-number-lt
set to2
succeeds.Permintaan asli akhirnya diproses, tetapi gagal karena menentukan kondisi bahwa nomor urut harus kurang dari 1 (yaitu,
if-sequence-num-lt
header diatur ke1
). Kesalahannya adalah SequenceNumberConditionNotMet (kode status HTTP 412 – Prasyarat Gagal).Membaca halaman 0 mengembalikan nilai yang diharapkan dari "Y".
Lihat juga
Mengotorisasi permintaan ke Azure Storage
Status dan kode galat
Atur batas waktu untuk operasi layanan Blob