Put Halaman

  • Artikel
  • 12 menit untuk membaca

Operasi ini Put Page menulis rentang halaman ke blob halaman.

Minta

Permintaan Put Page dapat dibuat sebagai berikut. HTTPS disarankan. 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 Storage Emulasi

Saat membuat permintaan terhadap layanan penyimpanan yang ditimulasi, tentukan nama host emulator dan port layanan Blob sebagai 127.0.0.1:10000, diikuti dengan nama akun penyimpanan yang ditimulasikan:

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 Azure Storage untuk Pengembangan dan Pengujian.

Parameter URI

Parameter tambahan berikut dapat ditentukan pada URI permintaan.

Parameter Deskripsi
timeout Opsional. Parameter timeout dinyatakan dalam hitung detik. Untuk informasi selengkapnya, lihat Mengatur Batas Waktu untuk Operasi Blob Service.

Judul Permintaan

Tabel berikut ini menjelaskan header permintaan yang diperlukan dan opsional.

Header Permintaan Deskripsi
Authorization Wajib diisi. Menentukan skema otorisasi, nama akun, dan tanda tangan. Untuk informasi selengkapnya, lihat Mengotorisasi permintaan ke Azure Storage.
Date atau x-ms-date Wajib diisi. 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. Untuk operasi hapus halaman, rentang halaman dapat mencapai nilai ukuran penuh blob.

Mengingat bahwa halaman harus diselaraskan dengan batas 512 byte, offset awal harus berupa modulus 512 dan offset akhir harus berupa modulus 512 – 1. Contoh rentang byte yang valid adalah 0-511, 512-1023, dll.

Blob service hanya menerima satu rentang byte untuk Range header, dan rentang byte harus ditentukan dalam format berikut: bytes=startByte-endByte.

Jika dan Rangex-ms-range ditentukan, layanan menggunakan nilai x-ms-range. Lihat Menentukan Header Rentang untuk Operasi Blob Service untuk informasi selengkapnya.
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.

Untuk operasi pembaruan halaman, rentang halaman dapat berukuran hingga 4 MiB. Untuk operasi hapus halaman, rentang halaman dapat mencapai nilai ukuran penuh blob.

Mengingat bahwa halaman harus diselaraskan dengan batas 512 byte, offset awal harus berupa modulus 512 dan offset akhir harus berupa modulus 512 – 1. Contoh rentang byte yang valid adalah 0-511, 512-1023, dll.

Blob service hanya menerima satu rentang byte untuk x-ms-range header, dan rentang byte harus ditentukan dalam format berikut: bytes=startByte-endByte.

Jika dan Rangex-ms-range ditentukan, layanan menggunakan nilai x-ms-range. Lihat Menentukan Header Rentang untuk Operasi Blob Service untuk informasi selengkapnya.
Content-Length Wajib diisi. Menentukan jumlah byte yang dikirimkan dalam isi permintaan. x-ms-page-write Ketika header diatur ke clear, nilai header ini harus diatur ke nol.
Content-MD5 Opsional. Hash MD5 dari konten halaman. Hash ini digunakan untuk memverifikasi integritas halaman selama transportasi. Ketika header ini ditentukan, layanan penyimpanan membandingkan hash konten yang telah tiba dengan nilai header ini.

Perhatikan bahwa hash MD5 ini tidak disimpan dengan blob.

Jika dua hash tidak cocok, operasi akan gagal dengan kode kesalahan 400 (Permintaan Buruk).
x-ms-content-crc64 Opsional. Hash CRC64 dari konten halaman. Hash ini digunakan untuk memverifikasi integritas halaman selama transportasi. Ketika header ini ditentukan, layanan penyimpanan membandingkan hash konten yang telah tiba dengan nilai header ini.

Perhatikan bahwa hash CRC64 ini tidak disimpan dengan blob.

Jika dua hash tidak cocok, operasi akan gagal dengan kode kesalahan 400 (Permintaan Buruk).

Jika header Content-MD5 dan x-ms-content-crc64 ada, permintaan akan gagal dengan 400 (Permintaan Buruk).

Header ini didukung dalam versi 2019-02-02 atau yang lebih baru.
x-ms-page-write: {update | clear} Wajib diisi. Anda dapat menentukan salah satu opsi berikut:

- Update: Menulis byte yang ditentukan oleh isi permintaan ke dalam rentang yang ditentukan. Header Range dan Content-Length harus cocok untuk melakukan pembaruan.
- Clear: Menghapus rentang yang ditentukan dan melepaskan ruang yang digunakan dalam penyimpanan untuk rentang tersebut. Untuk menghapus rentang, atur Content-Length header ke nol, dan Range header ke nilai yang menunjukkan rentang untuk menghapus, hingga ukuran blob maksimum.
x-ms-encryption-scope Opsional. Menunjukkan cakupan enkripsi yang akan digunakan untuk mengenkripsi konten permintaan. Header ini didukung dalam versi 2019-02-02 atau 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> Opsional. Jika nomor urut blob kurang dari atau sama dengan nilai yang ditentukan, permintaan akan dilanjutkan; jika tidak, itu gagal dengan kesalahan SequenceNumberConditionNotMet (kode status HTTP 412 – Prasyarat Gagal).
x-ms-if-sequence-number-lt: <num> Opsional. Jika nomor urut blob kurang dari nilai yang ditentukan, permintaan akan dilanjutkan; jika tidak, itu gagal dengan kesalahan SequenceNumberConditionNotMet (kode status HTTP 412 – Prasyarat Gagal).
x-ms-if-sequence-number-eq: <num> Opsional. Jika nomor urut blob sama dengan nilai yang ditentukan, permintaan akan dilanjutkan; jika tidak, itu gagal dengan kesalahan SequenceNumberConditionNotMet (kode status HTTP 412 – Prasyarat Gagal).
If-Modified-Since Opsional. Nilai DateTime. Tentukan header kondisional ini untuk menulis halaman hanya jika blob telah dimodifikasi sejak tanggal/waktu yang ditentukan. Jika blob belum dimodifikasi, blob service mengembalikan kode status 412 (Prasyarat Gagal).
If-Unmodified-Since Opsional. Nilai DateTime. Tentukan header kondisional ini untuk menulis halaman hanya jika blob belum dimodifikasi sejak tanggal/waktu yang ditentukan. Jika blob telah dimodifikasi, blob service mengembalikan kode status 412 (Prasyarat Gagal).
If-Match Opsional. Nilai ETag. Tentukan nilai ETag untuk header kondisional ini untuk menulis halaman hanya jika nilai ETag blob cocok dengan nilai yang ditentukan. Jika nilai tidak cocok, layanan Blob mengembalikan kode status 412 (Prasyarat Gagal).
If-None-Match Opsional. Nilai ETag.

Tentukan nilai ETag untuk header kondisional ini untuk menulis halaman hanya jika nilai ETag blob tidak cocok dengan nilai yang ditentukan. Jika nilainya identik, blob service mengembalikan kode status 412 (Prasyarat Gagal).
x-ms-client-request-id Opsional. Menyediakan nilai buram yang dihasilkan klien dengan batas karakter 1 KiB yang dicatat dalam log analitik saat pengelogan analitik penyimpanan diaktifkan. Menggunakan header ini sangat direkomendasikan untuk mengkorelasi aktivitas sisi klien dengan permintaan yang diterima oleh server. Untuk informasi selengkapnya, lihat Tentang Storage Analytics Logging dan Azure Logging: Menggunakan Log untuk Melacak Permintaan Storage.

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)

Dimulai dengan 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 set header yang sesuai) bersifat opsional.

Header permintaan Deskripsi
x-ms-encryption-key Wajib diisi. Kunci enkripsi AES-256 yang dikodekan Base64.
x-ms-encryption-key-sha256 Wajib diisi. Hash SHA256 yang dikodekan Base64 dari kunci enkripsi.
x-ms-encryption-algorithm: AES256 Wajib diisi. Menentukan algoritma yang akan digunakan untuk enkripsi. Nilai header ini harus AES256.

Isi Permintaan

Isi permintaan berisi konten halaman.

Permintaan Sampel: Perbarui Rentang Byte

  
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

Permintaan Sampel: Hapus Rentang Byte

  
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=

Respons

Respons mencakup kode status HTTP dan sekumpulan header respons.

Kode Status

Operasi yang berhasil mengembalikan kode status 201 (Dibuat).

Untuk informasi tentang kode status, lihat Status dan Kode Kesalahan.

Header 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.

Sintaks Deskripsi
ETag ETag untuk blob. Jika versi permintaan adalah 2011-08-18 atau yang lebih baru, nilai ETag akan berada dalam tanda kutip. ETag dapat digunakan untuk melakukan operasi kondisional Put Page 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 Representasi Nilai Date-Time di Header.

Setiap operasi tulis pada blob, termasuk pembaruan metadata atau properti blob, mengubah waktu terakhir blob yang dimodifikasi.
Content-MD5 Header ini dikembalikan sehingga klien dapat memeriksa integritas konten pesan. Nilai header ini dihitung oleh Blob service; itu belum tentu nilai yang sama yang ditentukan dalam header permintaan. Untuk versi 2019-02-02 atau yang lebih baru, Header ini hanya dikembalikan ketika permintaan memiliki header ini.
x-ms-content-crc64 Untuk versi 2019-02-02 atau yang lebih baru, header ini dikembalikan sehingga klien dapat memeriksa integritas konten pesan. Nilai header ini dihitung oleh Blob service; itu belum tentu nilai yang sama yang ditentukan dalam header permintaan.

Header ini dikembalikan ketika Content-MD5 header tidak ada dalam permintaan.
x-ms-blob-sequence-number Nomor urut saat ini untuk blob halaman.
x-ms-request-id Header ini secara unik mengidentifikasi permintaan yang dibuat dan dapat digunakan untuk memecahkan masalah permintaan. Untuk informasi selengkapnya, lihat Pemecahan 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 dimulainya respons.
x-ms-request-server-encrypted: true/false Versi 2015-12-11 atau yang lebih baru. Nilai header ini diatur ke true jika konten permintaan berhasil dienkripsi menggunakan algoritma yang ditentukan, dan false sebaliknya.
x-ms-encryption-key-sha256 Versi 2019-02-02 atau yang lebih baru. Header ini dikembalikan jika permintaan menggunakan kunci yang disediakan pelanggan untuk enkripsi, sehingga klien dapat memastikan konten permintaan berhasil dienkripsi menggunakan kunci yang disediakan.
x-ms-encryption-scope Versi 2019-02-02 atau yang lebih baru. Header ini dikembalikan jika permintaan menggunakan cakupan enkripsi, sehingga klien dapat memastikan konten permintaan berhasil dienkripsi menggunakan cakupan enkripsi.
x-ms-client-request-id Header ini dapat digunakan untuk memecahkan masalah permintaan dan respons yang sesuai. Nilai header ini sama dengan nilai x-ms-client-request-id header jika ada dalam permintaan dan nilainya paling banyak 1024 karakter ASCII yang terlihat. x-ms-client-request-id Jika header tidak ada dalam permintaan, header ini tidak akan ada dalam respons.

Isi Respons

Tidak ada.

Respons Sampel

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

Authorization

Operasi ini dapat dipanggil oleh pemilik akun dan oleh siapa pun dengan Tanda Tangan Akses Bersama yang memiliki izin untuk menulis ke blob ini atau kontainernya.

Keterangan

Operasi ini Put Page menulis rentang halaman ke blob halaman. Operasi ini hanya dapat dipanggil pada blob halaman yang ada. Ini tidak dapat dipanggil untuk membuat blob halaman baru, juga tidak dapat dipanggil pada blob blok. Memanggil Put Page dengan nama blob yang saat ini tidak ada mengembalikan kesalahan BlobNotFound (kode status HTTP 404 – Tidak Ditemukan).

Untuk membuat blob halaman baru, panggil Put Blob dan tentukan jenis blob yang akan dibuat sebagai blob halaman. Blob halaman mungkin berukuran hingga 8 TiB.

Jika blob memiliki sewa aktif, klien harus menentukan ID sewa yang valid pada permintaan untuk menulis halaman.

Operasi Pembaruan Halaman

Memanggil Put Page dengan Update opsi melakukan penulisan di tempat pada blob halaman yang ditentukan. Konten apa pun di halaman yang ditentukan ditimpa dengan pembaruan.

Penting

Jika server kehabisan waktu atau koneksi Anda ditutup selama Put Page, halaman mungkin atau mungkin belum diperbarui. Oleh karena itu, Anda harus terus mencoba kembali pembaruan sampai Anda menerima respons yang menunjukkan keberhasilan.

Setiap rentang halaman yang dikirimkan dengan Put Page untuk operasi pembaruan mungkin berukuran hingga 4 MiB. Rentang awal dan akhir halaman harus diselaraskan dengan batas 512 byte. Jika Anda mencoba mengunggah rentang halaman yang lebih besar dari 4MB, layanan mengembalikan kode status 413 (Entitas Permintaan Terlalu Besar).

Operasi Hapus Halaman

Memanggil Put Page dengan Clear opsi melepaskan ruang penyimpanan yang digunakan oleh halaman yang ditentukan. Halaman yang telah dibersihkan tidak lagi dilacak sebagai bagian dari blob halaman.

Halaman yang telah dihapus tidak lagi dikenakan biaya terhadap akun penyimpanan, karena sumber daya penyimpanannya telah dirilis. Satu-satunya pengecualian untuk ini adalah jika ada rekam jepret blob halaman yang ada; halaman dalam rekam jepret dikenakan biaya jika halaman yang sama tersebut tidak lagi ada sebagai bagian dari blob sumber.

Mengelola Masalah Konkurensi

Blob service menangani penulisan bersamaan ke halaman yang tumpang tindih secara berurutan: 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 ke Put Page. Urutan respons yang dikembalikan dari Blob service tidak selalu sesuai dengan urutan di mana respons dijalankan oleh layanan. Tetapi nilai Last-Modified selalu menunjukkan urutan di mana layanan memproses permintaan.

  • Anda dapat melakukan pembaruan secara kondisional berdasarkan ETag blob atau waktu terakhir diubah menggunakan konkurensi optimis. Pendekatan ini berfungsi dengan baik jika jumlah penulisan bersamaan relatif rendah. Gunakan header If-Matchpermintaan kondisional , , If-None-Match, If-Modified-Sincedan If-Unmodified-Since untuk tujuan ini.

  • Anda dapat memanggil Lease Blob untuk mengunci blob terhadap tulisan lain selama periode satu menit, atau lebih lama jika sewa diperpanjang.

  • Anda dapat menggunakan nomor urutan blob untuk memastikan bahwa mencoba kembali permintaan yang tidak ada respons 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

Ketika panggilan ke Put Page waktu habis atau tidak mengembalikan respons, 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, ada kemungkinan bahwa permintaan asli dapat 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:

  1. Permintaan Put Page untuk menulis nilai "X" ke halaman 0 kali habis atau tidak mengembalikan respons.

  2. Permintaan yang dicoba ulang untuk menulis nilai "X" ke halaman 0 berhasil.

  3. Permintaan untuk menulis nilai "Y" ke halaman 0 berhasil.

  4. Permintaan asli berhasil, menulis nilai "X" ke halaman 0.

  5. Membaca halaman 0 mengembalikan nilai "X", ketika klien berada 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 ketika Anda mencoba kembali permintaan, permintaan asli tidak akan berhasil. Untuk melakukannya, Anda harus menaikkan nomor urut sebelum mencoba kembali permintaan asli. Anda kemudian dapat menggunakan header nomor urutan bersyarat untuk memastikan bahwa permintaan gagal jika nomor urutnya tidak cocok dengan nomor urutan yang diharapkan. Urutan berikut mengilustrasikan pendekatan ini:

  1. Klien membuat blob halaman dengan Put Blob dan mengatur nomor urutannya ke 0.

  2. Permintaan Put Page untuk menulis nilai "X" ke halaman 0 dengan if-sequence-number-lt header diatur ke 1 waktu habis atau tidak mengembalikan respons.

  3. Klien memanggil Atur Properti Blob untuk memperbarui nomor urut menjadi 1.

  4. Permintaan yang dicoba ulang untuk menulis nilai "X" ke halaman 0 dengan if-sequence-number-lt diatur ke 2 berhasil.

  5. Permintaan untuk menulis nilai "Y" ke halaman 0 dengan if-sequence-number-lt diatur ke 2 berhasil.

  6. Permintaan asli akhirnya diproses, tetapi gagal karena menentukan kondisi bahwa nomor urut harus kurang dari 1 (artinya, if-sequence-num-lt header diatur ke 1). Kesalahannya adalah SequenceNumberConditionNotMet (kode status HTTP 412 – Prasyarat Gagal).

  7. Membaca halaman 0 mengembalikan nilai yang diharapkan dari "Y".

Lihat juga

Mengotorisasi permintaan ke Azure Storage
Status dan Kode Kesalahan
Mengatur Batas Waktu untuk Operasi Blob Service