Letakkan Blok

Artikel
06/13/2024

Operasi ini Put Block membuat blok baru yang akan diterapkan sebagai bagian dari blob.

Minta

Anda dapat membuat Put Block permintaan 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=block&blockid=id`	HTTP/1.1

Permintaan layanan penyimpanan yang ditimulasi

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

URI permintaan metode PUT	Versi HTTP
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=block&blockid=id`	HTTP/1.1

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

Parameter URI

Parameter	Deskripsi
`blockid`	Wajib diisi. Nilai string Base64 valid yang mengidentifikasi blok. Sebelum dikodekan, string harus berukuran kurang dari atau sama dengan 64 byte. Untuk blob tertentu, panjang nilai untuk `blockid` parameter harus berukuran sama untuk setiap blok. Catatan: String Base64 harus dikodekan URL.
`timeout`	Pilihan. Parameter `timeout` dinyatakan dalam hitung detik. Untuk informasi selengkapnya, lihat Mengatur waktu habis untuk operasi Blob service.

Header permintaan

Header permintaan yang diperlukan dan opsional dijelaskan dalam tabel berikut:

Meminta kop	Deskripsi
`Authorization`	Wajib diisi. Menentukan skema otorisasi, nama akun, dan tanda tangan. Lihat Mengotorisasi permintaan ke Azure Storage untuk informasi selengkapnya.
`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 Azure Storage Services.
`Content-Length`	Wajib diisi. Panjang konten blok dalam byte. Ukuran blok harus kurang dari atau sama dengan 4.000 mebibyte (MiB) untuk versi 2019-12-12 dan yang lebih baru. Lihat bagian Keterangan untuk batasan dalam versi yang lebih lama. Ketika panjang tidak disediakan, operasi gagal dengan kode status 411 (Panjang Diperlukan).
`Content-MD5`	Pilihan. Hash MD5 dari konten blok. Hash ini digunakan untuk memverifikasi integritas blok selama transportasi. Ketika header ini ditentukan, layanan penyimpanan membandingkan hash konten yang telah tiba dengan nilai header ini. Catatan: Hash MD5 ini tidak disimpan dengan blob. Jika dua hash tidak cocok, operasi gagal dengan kode kesalahan 400 (Permintaan Buruk).
`x-ms-content-crc64`	Opsional. Hash CRC64 dari konten blok. Hash ini digunakan untuk memverifikasi integritas blok selama transportasi. Ketika header ini ditentukan, layanan penyimpanan membandingkan hash konten yang telah tiba dengan nilai header ini. Catatan: Hash CRC64 ini tidak disimpan dengan blob. Jika dua hash tidak cocok, operasi gagal dengan kode kesalahan 400 (Permintaan Buruk). 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-encryption-scope`	Pilihan. Menunjukkan cakupan enkripsi yang akan digunakan untuk mengenkripsi konten permintaan. 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-client-request-id`	Pilihan. 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.

Header permintaan (kunci enkripsi yang disediakan pelanggan)

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

Meminta kop	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 blok.

Contoh permintaan

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: 2011-08-18  
x-ms-date: Sun, 25 Sep 2011 14:37:35 GMT  
Authorization: SharedKey myaccount:J4ma1VuFnlJ7yfk/Gu1GxzbfdJloYmBPWlfhZ/xn7GI=  
Content-Length: 1048576

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.

Header respons	Deskripsi
`Content-MD5`	Dikembalikan sehingga klien dapat memeriksa integritas konten pesan. Nilai header ini dihitung oleh Blob Storage, dan belum tentu nilai yang sama yang ditentukan di header permintaan. Untuk versi 2019-02-02 dan yang lebih baru, header ini dikembalikan hanya 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. Nilai header ini dihitung oleh Blob Storage, dan belum tentu nilai yang sama yang ditentukan di header permintaan. Header ini dikembalikan ketika `Content-md5` header tidak ada dalam permintaan.
`x-ms-request-id`	Secara unik mengidentifikasi permintaan yang dibuat, dan Anda dapat menggunakannya untuk memecahkan masalah permintaan. Untuk informasi selengkapnya, lihat Memecahkan masalah operasi API.
`x-ms-version`	Menunjukkan versi Blob Storage yang digunakan untuk menjalankan permintaan. Header ini dikembalikan untuk permintaan yang dibuat terhadap versi 2009-09-19 atau 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 dengan menggunakan algoritma 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-client-request-id`	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 nilai berisi tidak lebih dari 1.024 karakter ASCII yang terlihat. `x-ms-client-request-id` Jika header tidak ada dalam permintaan, header tidak ada dalam respons.

Respons sampel

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Transfer-Encoding: chunked  
x-ms-content-crc64: 77uWZTolTHU  
Date: Sun, 25 Sep 2011 23:47:09 GMT  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

Authorization

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

Penting

Microsoft merekomendasikan penggunaan ID Microsoft Entra dengan identitas terkelola untuk mengotorisasi permintaan ke Azure Storage. MICROSOFT Entra ID memberikan 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 ID Microsoft Entra, Anda dapat menggunakan kontrol akses berbasis peran Azure (Azure RBAC) untuk memberikan izin kepada prinsip keamanan. Prinsip keamanan dapat berupa 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 Blob service.

Untuk mempelajari selengkapnya tentang otorisasi menggunakan ID Microsoft Entra, lihat Mengotorisasi akses ke blob menggunakan ID Microsoft Entra.

Izin

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

Tindakan Azure RBAC:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Peran bawaan yang paling tidak istimewa:Kontributor Data Blob Penyimpanan

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

Tanda tangan akses bersama (SAS) menyediakan akses delegasi yang aman ke sumber daya di akun penyimpanan. Dengan SAS, Anda memiliki kontrol terperinci atas bagaimana klien dapat mengakses data. Anda dapat menentukan sumber daya apa yang dapat diakses klien, izin apa yang mereka miliki ke sumber daya tersebut, dan berapa lama SAS valid.

Operasi ini Put Block mendukung tiga jenis tanda tangan akses bersama: SAS delegasi pengguna, SAS layanan, dan SAS akun.

Sebagai praktik terbaik keamanan, kami sarankan Anda menggunakan kredensial Microsoft Entra daripada kunci akun penyimpanan, yang dapat lebih mudah disusupi. Jika desain aplikasi Anda memerlukan tanda tangan akses bersama, gunakan kredensial Microsoft Entra untuk membuat SAS delegasi pengguna, jika memungkinkan.

Ketika akses Kunci Bersama tidak diizinkan untuk akun penyimpanan, token SAS layanan atau token SAS akun tidak akan diizinkan berdasarkan permintaan ke Blob Storage. Untuk mempelajari lebih lanjut, lihat Memahami bagaimana melarang Kunci Bersama memengaruhi token SAS.

Delegasi pengguna SAS

SAS delegasi pengguna diamankan dengan kredensial Microsoft Entra dan juga oleh izin yang ditentukan untuk SAS.

Memanggil Put Block operasi menggunakan token SAS yang didelegasikan ke kontainer atau sumber daya blob memerlukan izin Tulis (w) sebagai bagian dari token SAS delegasi pengguna.

Untuk mempelajari selengkapnya tentang SAS delegasi pengguna, lihat Membuat SAS delegasi pengguna.

Layanan SAS

Layanan SAS diamankan dengan kunci akun penyimpanan. SAS layanan mendelegasikan akses ke sumber daya dalam satu layanan Azure Storage, seperti penyimpanan blob.

Memanggil Put Block operasi menggunakan token SAS yang didelegasikan ke kontainer atau sumber daya blob memerlukan izin Tulis (w) sebagai bagian dari token SAS layanan.

Untuk mempelajari selengkapnya tentang layanan SAS, lihat Membuat layanan SAS.

Akun SAS

Akun SAS diamankan dengan kunci akun penyimpanan. Akun SAS delegasikan akses ke sumber daya di satu atau beberapa layanan penyimpanan. Semua operasi yang tersedia melalui layanan atau delegasi pengguna SAS juga tersedia melalui akun SAS.

Tabel berikut menunjukkan jenis sumber daya yang ditandatangani dan izin yang ditandatangani untuk menentukan saat mendelegasikan akses:

Operasi	Layanan yang ditandatangani	Jenis sumber daya yang ditandatangani	Izin yang ditandatangani
Letakkan Blok	Blob (b)	Objek (o)	Tulis (w)

Untuk mempelajari selengkapnya tentang akun SAS, lihat Membuat akun SAS.

Keterangan

Put Block mengunggah blok untuk dimasukkan di masa mendatang dalam blob blok. Setiap blok dalam blob blok bisa menjadi ukuran yang berbeda. Blob blok dapat mencakup maksimum 50.000 blok yang diterapkan.

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 12-12-2019 dan yang lebih baru	4.000 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 yang lebih lama dari 2016-05-31	4 MiB	Sekitar 195 gibibyte (GiB) (4 MiB × 50.000 blok)	64 MiB

Jumlah maksimum blok yang tidak dikomit yang mungkin terkait dengan blob adalah 100.000. Jika jumlah ini terlampaui, layanan mengembalikan kode status 409 (RequestEntityTooLargeBlockCountExceedsLimit).

Setelah mengunggah sekumpulan blok, Anda dapat membuat atau memperbarui blob di server dari set ini dengan memanggil operasi Put Block List . Setiap blok dalam set diidentifikasi oleh ID blok yang unik dalam blob tersebut. ID blok dilingkup ke blob tertentu, sehingga blob yang berbeda dapat memiliki blok dengan ID yang sama.

Jika Anda memanggil Put Block pada blob yang belum ada, blob blok baru dibuat dengan panjang konten 0. Blob ini dijumlahkan oleh List Blobs operasi jika include=uncommittedblobs opsi ditentukan. Blokir atau blok yang Anda unggah tidak diterapkan hingga Anda memanggil Put Block List blob baru. Blob yang dibuat dengan cara ini dipertahankan di server selama seminggu. Jika Anda belum menambahkan lebih banyak blok atau blok yang diterapkan ke blob dalam periode waktu tersebut, blob adalah sampah yang dikumpulkan.

Blok yang telah berhasil diunggah dengan Put Block operasi tidak menjadi bagian dari blob sampai diterapkan dengan Put Block List. Sebelum Put Block List dipanggil untuk menerapkan blob baru atau yang diperbarui, setiap panggilan ke Get Blob mengembalikan konten blob tanpa dimasukkannya blok yang tidak dikomit.

Jika Anda mengunggah blok yang memiliki ID blok yang sama dengan blok lain yang belum dilakukan, blok terakhir yang diunggah dengan ID tersebut akan dilakukan pada operasi yang berhasil Put Block List berikutnya.

Setelah Put Block List dipanggil, semua blok yang tidak dikomit yang ditentukan dalam daftar blokir diterapkan sebagai bagian dari blob baru. Setiap blok yang tidak dikomit yang tidak ditentukan dalam daftar blokir untuk blob adalah sampah yang dikumpulkan dan dihapus dari Blob Storage. Setiap blok yang tidak dilakukan juga merupakan sampah yang dikumpulkan jika tidak ada panggilan yang berhasil ke Put Block atau Put Block List pada blob yang sama dalam seminggu setelah operasi terakhir yang berhasil Put Block . Jika Put Blob dipanggil pada blob, setiap blok yang tidak dikomit adalah sampah yang dikumpulkan.

Jika blob memiliki sewa aktif, klien harus menentukan ID sewa yang valid pada permintaan untuk menulis blok ke blob. 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).

Untuk blob tertentu, semua ID blok harus memiliki panjang yang sama. Jika blok diunggah dengan ID blok dengan panjang yang berbeda dari ID blok untuk blok yang tidak diterapkan yang ada, layanan mengembalikan kode respons kesalahan 400 (Permintaan Buruk).

Jika Anda mencoba mengunggah blok yang lebih besar dari 4.000 MiB untuk versi 2019-12-12 atau yang lebih baru, lebih besar dari 100 MiB untuk versi 2016-05-31 atau yang lebih baru, atau lebih besar dari 4 MiB untuk versi yang lebih lama, layanan mengembalikan kode status 413 (Entitas Permintaan Terlalu Besar). Layanan ini juga mengembalikan informasi tambahan tentang kesalahan dalam respons, termasuk ukuran blok maksimum yang diizinkan, dalam byte.

Put Block Panggilan tidak memperbarui waktu terakhir yang dimodifikasi dari blob yang ada.

Memanggil Put Block pada blob halaman mengembalikan kesalahan.

Memanggil Put Block pada blob yang diarsipkan mengembalikan kesalahan, dan memanggilnya pada hot blob atau cool tidak mengubah tingkat blob.

Billing

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

Operasi	Jenis akun penyimpanan	Kategori penagihan
Letakkan Blok	Objek besar biner blok premium Tujuan umum standar v2 Tujuan umum standar v1	Operasi tulis¹

¹Put Block operasi menulis blok ke penyimpanan sementara menggunakan tingkat akses default akun penyimpanan. Misalnya, jika Anda mengunggah blob ke tingkat arsip, operasi apa pun Put Block yang merupakan bagian dari unggahan dikenakan biaya sebagai operasi tulis berdasarkan tingkat akses default akun penyimpanan, bukan tingkat tujuan. Put Block List dan Put Blob operasi, bagaimanapun, dibebankan sebagai operasi tulis berdasarkan tingkat tujuan blob.

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

Lihat juga

Mengotorisasi permintaan ke Azure Storage
Status dan kode galat
Kode kesalahan blob service
Mengatur waktu habis untuk operasi Blob service

Bagikan melalui