Masukkan Daftar Blokir

Operasi menulis Put Block List blob dengan menentukan daftar ID blok yang membentuk blob. Untuk ditulis sebagai bagian dari blob, blok harus berhasil ditulis ke server dalam operasi Put Block sebelumnya.

Anda dapat memanggil Put Block List untuk memperbarui blob dengan hanya mengunggah blok yang telah berubah dan kemudian menerapkan blok baru dan yang sudah ada bersama-sama. Anda dapat melakukannya dengan menentukan apakah akan melakukan commit block dari daftar blokir yang dilakukan atau dari daftar blokir yang tidak di-commit atau untuk melakukan versi blok yang paling baru diunggah, daftar mana pun yang dimilikinya.

Permintaan

Anda dapat membuat permintaan Put Block List sebagai berikut. Kami menyarankan agar Anda menggunakan HTTPS. Ganti akun saya dengan nama akun penyimpanan Anda:

URI permintaan metode PUT Versi HTTP
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1

Permintaan layanan penyimpanan yang ditimulasi

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=blocklist HTTP/1.1

Emulator penyimpanan hanya mendukung ukuran blob hingga 2 gibibyte (GiB).

Untuk informasi selengkapnya, lihat Menggunakan emulator Azurite untuk pengembangan Azure Storage lokal.

URI Parameter

Anda dapat menentukan parameter tambahan berikut pada URI permintaan:

Parameter Deskripsi
timeout Optional. Parameter timeout dinyatakan dalam hitung detik. Untuk informasi selengkapnya, lihat Mengatur batas waktu untuk operasi layanan Blob.

Tajuk permintaan

Header permintaan yang diperlukan dan opsional dijelaskan dalam tabel berikut:

Header 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.
Content-Length Dibutuhkan. Panjang konten permintaan, dalam byte. Header ini mengacu pada panjang konten daftar blok, bukan blob itu sendiri.
Content-MD5 Optional. Hash MD5 dari konten permintaan. Hash ini digunakan untuk memverifikasi integritas konten permintaan selama transportasi. Jika dua hash tidak cocok, operasi gagal dengan kode kesalahan 400 (Permintaan Buruk).

Header ini dikaitkan dengan konten permintaan, dan bukan dengan konten blob itu sendiri.
x-ms-content-crc64 Optional. Hash CRC64 dari konten permintaan. Hash ini digunakan untuk memverifikasi integritas konten permintaan selama transportasi. Jika dua hash tidak cocok, operasi gagal dengan kode kesalahan 400 (Permintaan Buruk).

Header ini dikaitkan dengan konten permintaan, dan bukan dengan konten blob itu sendiri.

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

Header ini didukung dalam versi 2019-02-02 dan yang lebih baru.
x-ms-blob-cache-control Optional. Mengatur kontrol cache blob. Jika properti ini ditentukan, properti ini disimpan dengan blob dan dikembalikan dengan permintaan baca.

Jika properti tidak ditentukan dengan permintaan, properti akan dihapus untuk blob jika permintaan berhasil.
x-ms-blob-content-type Optional. Mengatur jenis konten blob. Jika ditentukan, properti ini disimpan dengan blob dan dikembalikan dengan permintaan baca.

Jika jenis konten tidak ditentukan, jenis konten diatur ke jenis default, yaitu application/octet-stream.
x-ms-blob-content-encoding Optional. Mengatur pengkodean konten blob. Jika ditentukan, properti ini disimpan dengan blob dan dikembalikan dengan permintaan baca.

Jika properti tidak ditentukan dengan permintaan, properti akan dihapus untuk blob jika permintaan berhasil.
x-ms-blob-content-language Optional. Mengatur bahasa konten blob. Jika ditentukan, properti ini disimpan dengan blob dan dikembalikan dengan permintaan baca.

Jika properti tidak ditentukan dengan permintaan, properti akan dihapus untuk blob jika permintaan berhasil.
x-ms-blob-content-md5 Optional. Hash MD5 dari konten blob. Hash ini tidak divalidasi, karena hash untuk masing-masing blok divalidasi saat masing-masing diupload.

Operasi Get Blob mengembalikan nilai header ini di header respons Content-MD5.

Jika properti ini tidak ditentukan dengan permintaan, properti ini dihapus untuk blob jika permintaan berhasil.
x-ms-meta-name:value Optional. Pasangan nama-nilai yang ditentukan pengguna yang terkait dengan blob.

Pada versi 2009-09-19, nama metadata harus mematuhi aturan penamaan untuk pengidentifikasi C#.
x-ms-encryption-scope Optional. Menunjukkan cakupan enkripsi yang akan digunakan untuk mengenkripsi blob. Nilai ini harus sesuai dengan cakupan enkripsi yang digunakan untuk mengenkripsi semua blok yang sedang dilakukan. Header ini didukung dalam versi 2019-02-02 dan yang lebih baru.
x-ms-encryption-context Optional. Defaultnya adalah "Kosong". Jika nilainya ditetapkan, itu akan mengatur metadata sistem blob. Panjang maks-1024. Hanya valid saat Namespace Hierarki diaktifkan untuk akun tersebut. Header ini didukung dalam versi 2021-08-06 dan yang lebih baru.
x-ms-tags Optional. Mengatur tag yang dikodekan string kueri yang ditentukan pada blob. Untuk informasi tambahan, lihat bagian Keterangan . Didukung dalam versi 2019-12-12 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-client-request-id Optional. Menyediakan nilai buram yang dihasilkan klien dengan batas karakter 1 kibibyte (KiB) yang dicatat dalam log analitik saat pengelogan analitik penyimpanan dikonfigurasi. Kami sangat menyarankan Anda menggunakan header ini untuk menghubungkan aktivitas sisi klien dengan permintaan yang diterima server.
x-ms-blob-content-disposition Optional. Mengatur header Content-Disposition blob. Tersedia untuk versi 2013-08-15 dan yang lebih baru.

Bidang Content-Disposition header menyampaikan informasi tambahan tentang cara memproses payload respons, dan dapat digunakan untuk melampirkan metadata tambahan. Misalnya, jika diatur ke attachment, header ini menunjukkan bahwa agen pengguna tidak boleh menampilkan respons, tetapi harus menampilkan dialog Simpan Sebagai.

Respons dari operasi Dapatkan Blob dan Dapatkan Properti Blob mencakup header disposisi konten.
x-ms-access-tier Optional. Versi 2018-11-09 dan yang lebih baru. Menunjukkan tingkat yang akan diatur pada blob. Untuk blob blok, header ini didukung pada penyimpanan blob atau akun v2 tujuan umum hanya dengan versi 2018-11-09 dan yang lebih baru. Nilai yang valid untuk tingkat blob blok adalah Hot, Cool, Cold, Smart dan Archive.
Catatan: tingkatCold didukung untuk versi 2021-12-02 dan yang lebih baru. Smart Tier didukung untuk versi 2026-02-06 dan yang lebih baru, dan saat ini dalam pratinjau publik.
Untuk informasi terperinci tentang tingkatan blob blok, lihat Tingkat penyimpanan blob.
x-ms-immutability-policy-until-date Versi 2020-06-12 dan yang lebih baru. Menentukan tanggal retensi-sampai yang akan ditetapkan pada blob. Ini adalah tanggal hingga blob dapat dilindungi agar tidak dimodifikasi atau dihapus. Mengikuti format RFC1123.
x-ms-immutability-policy-mode Versi 2020-06-12 dan yang lebih baru. Menentukan mode kebijakan kekekalan yang akan diatur pada blob. Nilai yang berlaku adalah unlocked atau locked. Nilai menunjukkan unlocked bahwa pengguna dapat mengubah kebijakan dengan menambah atau mengurangi tanggal retensi- . Nilai menunjukkan locked bahwa tindakan ini dilarang.
x-ms-legal-hold Versi 2020-06-12 dan yang lebih baru. Menentukan pembekuan hukum yang akan diatur pada blob. Nilai yang valid adalah true dan false.
x-ms-expiry-option Optional. Versi 2023-08-03 dan yang lebih baru. Menentukan opsi tanggal kedaluwarsa untuk permintaan, lihat ExpiryOption. Header ini valid untuk akun dengan namespace hierarki diaktifkan.
x-ms-expiry-time Optional. Versi 2023-08-03 dan yang lebih baru. Menentukan waktu ketika blob diatur kedaluwarsa. Format untuk tanggal kedaluwarsa bervariasi sesuai dengan x-ms-expiry-option. Untuk informasi selengkapnya, lihatExpiryOption . Header ini valid untuk akun dengan namespace hierarki diaktifkan.

Yang expiryTime sudah ada pada blob tidak dihapus jika permintaan tidak berisi nilai baru expiryTime

Operasi ini juga mendukung penggunaan header bersyarat untuk menerapkan daftar blokir hanya jika kondisi tertentu terpenuhi. Untuk informasi selengkapnya, lihat Menentukan header kondisional untuk operasi Blob Storage.

Header permintaan (kunci enkripsi yang disediakan pelanggan)

Pada versi 2019-02-02, Anda dapat menentukan header berikut pada permintaan untuk mengenkripsi blob dengan kunci yang disediakan pelanggan. Enkripsi dengan kunci yang disediakan pelanggan (dan kumpulan header yang sesuai) bersifat opsional.

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

Badan permintaan

Di isi permintaan, Anda dapat menentukan daftar blokir yang harus diperiksa oleh Blob Storage untuk blok yang diminta. Dengan cara ini, Anda dapat memperbarui blob yang ada dengan menyisipkan, mengganti, atau menghapus blok individual, daripada mengunggah ulang seluruh blob. Setelah mengunggah blok atau blok yang telah berubah, Anda dapat menerapkan versi baru blob dengan menerapkan blok baru bersama dengan blok yang ada yang ingin Anda simpan.

Untuk memperbarui blob, Anda dapat menentukan bahwa layanan harus mencari ID blok dalam daftar blokir yang diterapkan, dalam daftar blokir yang tidak diterapkan, atau dalam daftar blokir yang tidak diterapkan terlebih dahulu dan kemudian di daftar blokir yang diterapkan. Untuk menunjukkan pendekatan mana yang akan digunakan, tentukan ID blok yang berada dalam elemen XML yang sesuai dalam isi permintaan, sebagai berikut:

  • Tentukan ID blok dalam Committed elemen untuk menunjukkan bahwa Blob Storage hanya harus mencari daftar blokir yang diterapkan untuk blok bernama. Jika blok tidak ditemukan dalam daftar blokir yang diterapkan, blok tersebut tidak ditulis sebagai bagian dari blob, dan Blob Storage mengembalikan kode status 400 (Permintaan Buruk).

  • Tentukan ID blok dalam Uncommitted elemen untuk menunjukkan bahwa Blob Storage hanya boleh mencari daftar blokir yang tidak diterapkan untuk blok bernama. Jika blok tidak ditemukan dalam daftar blokir yang tidak diterapkan, blok tersebut tidak ditulis sebagai bagian dari blob, dan Blob Storage mengembalikan kode status 400 (Permintaan Buruk).

  • Tentukan ID blok dalam Latest elemen untuk menunjukkan bahwa Blob Storage harus terlebih dahulu mencari daftar blokir yang tidak diterapkan. Jika blok ditemukan dalam daftar yang tidak diterapkan, versi blok tersebut adalah yang terbaru dan harus ditulis ke blob. Jika blok tidak ditemukan dalam daftar yang tidak diterapkan, layanan harus mencari daftar blokir yang diterapkan untuk blok bernama dan menulis blok tersebut ke blob jika ditemukan.

Isi permintaan untuk versi Put Block List ini menggunakan format XML berikut:

<?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>

Permohonan sampel

Untuk mendemonstrasikan Put Block List, asumsikan Anda telah mengunggah tiga blok yang sekarang ingin Anda lakukan. Contoh berikut menerapkan blob baru dengan menunjukkan bahwa versi terbaru dari setiap blok yang tercantum harus digunakan. Tidak perlu mengetahui apakah pemblokiran ini telah dilakukan.

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>

Selanjutnya, mari kita asumsikan bahwa Anda ingin memperbarui blob. Blob baru memiliki perubahan berikut:

  • Blok baru dengan ID ANAAAA==. Pemblokiran ini harus terlebih dahulu diunggah dengan panggilan ke Put Block, dan muncul di daftar blokir yang tidak di-commit hingga panggilan ke Put Block List.

  • Versi terbaru dari blok dengan ID AZAAAA==. Pemblokiran ini harus terlebih dahulu diunggah dengan panggilan ke Put Block, dan muncul di daftar blokir yang tidak di-commit hingga panggilan ke Put Block List.

  • Penghapusan blok dengan ID AAAAAA==. Karena blok ini tidak disertakan dalam panggilan berikutnya ke Put Block List, blok secara efektif dihapus dari blob.

Contoh berikut menunjukkan panggilan ke Put Block List yang memperbarui blob:

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>

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 .

Jawaban Deskripsi
ETag Tag entitas berisi nilai yang dapat digunakan klien untuk melakukan operasi bersyarat GET/PUT dengan menggunakan header permintaan If-Match . Jika versi permintaan adalah 2011-08-18 atau yang lebih baru, nilai ETag diapit dalam tanda kutip.
Last-Modified Tanggal/waktu gumpalan terakhir diubah. Format tanggal mengikuti RFC 1123. Untuk informasi selengkapnya, lihat Mewakili nilai tanggal/waktu di header.

Setiap operasi yang memodifikasi blob, termasuk pembaruan metadata atau properti blob, mengubah waktu modifikasi terakhir blob.
Content-MD5 Dikembalikan sehingga klien dapat memeriksa integritas konten pesan. Header ini mengacu pada konten permintaan (dalam hal ini, daftar blok dan bukan konten blob itu sendiri). Untuk versi 2019-02-02 dan yang lebih baru, header ini hanya dikembalikan ketika permintaan memiliki header ini.
x-ms-content-crc64 Untuk versi 2019-02-02 dan yang lebih baru, header ini dikembalikan sehingga klien dapat memeriksa integritas konten pesan. Header ini mengacu pada konten permintaan (dalam hal ini, daftar blok dan bukan konten blob itu sendiri).

Header ini dikembalikan saat Content-md5 header tidak ada dalam permintaan.
x-ms-request-id Mengidentifikasi permintaan yang dibuat secara unik, dan Anda dapat menggunakannya untuk memecahkan masalah permintaan. Untuk informasi selengkapnya, lihat Memecahkan masalah operasi API.
x-ms-version Versi Blob Storage yang digunakan untuk mengeksekusi 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 kapan 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 menggunakan algoritme yang ditentukan. Jika tidak, nilai diatur ke false.
x-ms-encryption-key-sha256 Versi 2019-02-02 dan yang lebih baru. Header ini 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. Header ini dikembalikan jika permintaan menggunakan cakupan enkripsi, sehingga klien dapat memastikan bahwa konten permintaan berhasil dienkripsi dengan menggunakan cakupan enkripsi.
x-ms-version-id: <DateTime> Versi 2019-12-12 dan yang lebih baru. Mengembalikan nilai DateTime buram yang secara unik mengidentifikasi blob. Nilai header ini menunjukkan versi blob, dan dapat digunakan dalam permintaan berikutnya untuk mengakses blob.
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 ada dalam respons.

Contoh tanggapan

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>

Authorization

Otorisasi diperlukan saat memanggil operasi akses data apa pun di Azure Storage. Anda dapat mengotorisasi operasi Put Block List seperti yang dijelaskan di bawah ini.

Jika permintaan menentukan tag dengan header permintaan x-ms-tags, pemanggil harus memenuhi persyaratan otorisasi Mengatur Tag Blob operasi.

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.

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.

Permissions

Tercantum di bawah ini adalah tindakan RBAC yang diperlukan untuk pengguna, grup, identitas terkelola, atau perwakilan layanan Microsoft Entra untuk memanggil operasi Put Block List, dan peran Azure RBAC bawaan yang paling tidak istimewa yang mencakup tindakan ini:

Untuk mempelajari selengkapnya tentang menetapkan peran menggunakan Azure RBAC, lihat Menetapkan peran Azure untuk akses ke data blob.

Komentar

Operasi ini Put Block List memberlakukan urutan di mana blok akan digabungkan untuk membuat blob.

ID blok yang sama dapat ditentukan lebih dari satu kali dalam daftar blok. Jika ID blok ditentukan lebih dari satu kali, ID blok mewakili rentang byte di masing-masing lokasi tersebut dalam daftar blokir untuk blob penerapan akhir. Jika ID blok muncul lebih dari sekali dalam daftar, kedua instans ID blok harus ditentukan dalam daftar blokir yang sama. Dengan kata lain, kedua instance harus ditentukan dalam Committed elemen, elemen, Uncommitted atau Latest elemen.

Dengan Put Block List, Anda dapat memodifikasi blob yang ada dengan menyisipkan, memperbarui, atau menghapus blok individual tanpa harus mengunggah seluruh blob lagi. Anda dapat menentukan ID blok dari daftar blokir yang diterapkan saat ini dan daftar blokir yang tidak diterapkan untuk membuat blob baru atau memperbarui konten blob yang ada. Dengan cara ini, Anda dapat memperbarui blob dengan menentukan beberapa blok baru dari daftar blokir yang tidak diterapkan, dan sisanya dari daftar blokir yang diterapkan, yang sudah menjadi bagian dari blob yang ada.

Jika ID blok ditentukan dalam Latest elemen, dan ID blok yang sama ada di daftar blokir yang diterapkan dan tidak diterapkan, Put Block List akan menerapkan blok dari daftar blokir yang tidak diterapkan. Jika ID blok ada dalam daftar blokir yang diterapkan tetapi tidak dalam daftar blokir yang tidak diterapkan, akan melakukan pemblokiran dari daftar blokir yang diterapkan. Put Block List

Setiap blok dalam blob blok dapat memiliki ukuran yang berbeda. Blob blok dapat menyertakan maksimum 50.000 blok yang diterapkan. Jumlah maksimum blok yang tidak diterapkan yang mungkin dikaitkan dengan blob adalah 100.000.

Tabel berikut menjelaskan ukuran blok dan blob maksimum yang diizinkan, berdasarkan versi layanan:

Versi layanan Ukuran blok maksimum (melalui)Put Block Ukuran blob maksimum (melalui Put Block List) Ukuran blob maksimum melalui operasi tulis tunggal (melalui Put Blob)
Versi 2019-12-12 dan yang lebih baru 4.000 mebibyte (MiB) Sekitar 190,7 tebibyte (TiB) (4.000 MiB × 50.000 blok) 5.000 MiB
Versi 2016-05-31 hingga 2019-07-07 100 MiB Sekitar 4,75 TiB (100 MiB × 50.000 blok) 256 MiB
Versi lebih awal dari 31-05-2016 4 MiB Sekitar 195 GiB (4 MiB × 50.000 blok) 64 MiB

Saat Anda memanggil Put Block List untuk memperbarui blob yang ada, properti dan metadata blob yang ada ditimpa. Namun, rekam jepret yang ada dipertahankan dengan blob. Anda dapat menggunakan header permintaan bersyarat untuk melakukan operasi hanya jika kondisi tertentu terpenuhi.

Jika Put Block List operasi gagal karena blok yang hilang, Anda perlu mengunggah blok yang hilang.

Setiap blok yang tidak diterapkan adalah sampah yang dikumpulkan jika tidak ada panggilan yang berhasil ke Put Block atau Put Block List pada blob dalam waktu seminggu setelah operasi terakhir yang berhasil Put Block . Jika Put Blob dipanggil pada blob, blok yang tidak diterapkan akan dikumpulkan sampah.

Jika tag disediakan di x-ms-tags header, tag tersebut harus dikodekan string kueri. Kunci dan nilai tag harus sesuai dengan persyaratan penamaan dan panjang, seperti yang ditentukan dalam Set Blob Tags. Selanjutnya, x-ms-tags header mungkin berisi tag berukuran hingga 2 KiB. Jika lebih banyak tag diperlukan, gunakan operasi Atur Tag Blob .

Jika blob memiliki sewa aktif, klien harus menentukan ID sewa yang valid pada permintaan untuk menerapkan daftar blokir. Jika klien tidak menentukan ID sewa atau menentukan ID sewa yang tidak valid, Blob Storage mengembalikan kode status 412 (Prasyarat Gagal). Jika klien menentukan ID sewa tetapi blob tidak memiliki sewa aktif, Blob Storage juga mengembalikan kode status 412 (Prasyarat Gagal). Jika klien menentukan ID sewa pada blob yang belum ada, Blob Storage mengembalikan kode status 412 (Prasyarat Gagal) untuk permintaan yang dibuat terhadap versi 2013-08-15 atau yang lebih baru. Untuk versi sebelumnya, Blob Storage mengembalikan kode status 201 (Dibuat).

Jika blob memiliki sewa aktif dan Anda memanggil Put Block List untuk memperbarui blob, sewa dipertahankan pada blob yang diperbarui.

Put Block List hanya berlaku untuk blob blok. Memanggil Put Block List blob halaman menghasilkan kode status 400 (Permintaan Buruk).

Menimpa blob archive gagal. Jika tidak, blob mewarisi tingkat dari blob lama jika x-ms-access-tier header tidak disediakan.

Billing

Permintaan harga dapat berasal dari klien yang menggunakan API Blob Storage, baik secara langsung melalui BLob Storage REST API, atau dari pustaka klien Azure Storage. Permintaan ini mengumpulkan biaya per transaksi. Jenis transaksi memengaruhi bagaimana akun ditagih. Misalnya, transaksi baca bertambah ke kategori penagihan yang berbeda dari transaksi tulis. Tabel berikut ini memperlihatkan kategori penagihan untuk permintaan Put Block List berdasarkan jenis akun penyimpanan:

Pengoperasian Jenis akun penyimpanan Kategori penagihan
Masukkan Daftar Blokir Blok Blob Premium
Standar tujuan umum versi 2
Standar tujuan umum v1		 Operasi tulis

Untuk mempelajari tentang harga untuk kategori penagihan yang ditentukan, lihat Harga Azure Blob Storage.

Baca juga

Memahami blob blok, menambahkan blob, dan blob halaman
Mengotorisasi permintaan ke Azure Storage
Status dan kode galat
Kode kesalahan layanan blob
Atur batas waktu untuk operasi layanan Blob

  • Last updated on