Tambahkan Blok

Operasi ini Append Block menerapkan blok data baru ke akhir blob tambahan yang ada.

Operasi hanya Append Block diizinkan jika blob dibuat dengan x-ms-blob-type set to AppendBlob. Append Block hanya didukung pada versi 2015-02-21 versi atau yang lebih baru.

Permohonan

Anda dapat membuat permintaan Append Block 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=appendblock HTTP/1.1

Saat Anda membuat permintaan terhadap layanan penyimpanan yang diemulasi, tentukan nama host emulator dan port Azure Blob Storage 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=appendblock HTTP/1.1

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

URI Parameter

Pengaturan Description
timeout Optional. Parameter dinyatakan timeout dalam detik. Untuk informasi selengkapnya, lihat Mengatur batas waktu untuk operasi Azure Blob Storage.

Tajuk permintaan

Tabel berikut ini menjelaskan header permintaan yang diperlukan dan opsional.

Tajuk permintaan Description
Authorization Dibutuhkan. Menentukan skema otorisasi, nama akun, dan tanda tangan. Lihat Mengotorisasi permintaan ke Azure Storage untuk informasi selengkapnya.
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 resmi. Menentukan versi operasi yang akan digunakan untuk permintaan ini. Untuk informasi selengkapnya, lihat Penerapan versi untuk layanan Azure Storage.
Content-Length Dibutuhkan. Panjang konten blok dalam byte. Ukuran blok harus kurang dari atau sama dengan ukuran 100 MiB (pratinjau) untuk versi 2022-11-02 dan yang lebih baru. Lihat bagian Keterangan untuk batasan di versi yang lebih lama.

Ketika panjang tidak disediakan, operasi akan gagal dengan kode status 411 (Panjang Diperlukan).
Content-MD5 Optional. Hash MD5 dari konten blok. Hash ini digunakan untuk memverifikasi integritas blok selama transportasi. Saat 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 kedua hash tidak cocok, operasi akan gagal dengan kode kesalahan 400 (Permintaan Buruk).
x-ms-content-crc64 Optional. Hash CRC64 dari konten blok tambahan. Hash ini digunakan untuk memverifikasi integritas blok penambahan selama transportasi. Saat 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 kedua hash tidak cocok, operasi akan gagal dengan kode kesalahan 400 (Permintaan Buruk).

Jika keduanya Content-MD5 dan x-ms-content-crc64 header ada, permintaan akan gagal dengan kode kesalahan 400.

Header ini didukung dalam versi 2019-02-02 atau yang lebih baru.
x-ms-encryption-scope Optional. 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-client-request-id Optional. 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-blob-condition-maxsize Header bersyarat opsional. Menentukan panjang maksimum dalam byte yang diizinkan untuk blob penambahan. Jika Append Block operasi menyebabkan blob melebihi batas tersebut, atau jika ukuran blob sudah lebih besar dari nilai yang ditentukan dalam header ini, permintaan gagal dengan kode kesalahan 412 (Prasyarat Gagal).
x-ms-blob-condition-appendpos Header bersyarat opsional, hanya digunakan untuk Append Block operasi. Angka menunjukkan offset byte untuk dibandingkan. Append Block berhasil hanya jika posisi penambahan sama dengan angka ini. Jika tidak, permintaan gagal dengan kode kesalahan 412 (Prasyarat Gagal).

Operasi ini mendukung penggunaan header bersyarat tambahan untuk memastikan bahwa API berhasil hanya jika kondisi tertentu terpenuhi. Untuk informasi selengkapnya, lihat Menentukan header bersyarat untuk operasi Azure Blob Storage.

Header permintaan (kunci enkripsi yang disediakan pelanggan)

Dimulai dengan 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.

Tajuk permintaan Description
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 algoritme yang akan digunakan untuk enkripsi. Nilai header ini harus .AES256

Header permintaan (isi terstruktur)

Pada versi 05-01-2025, header berikut dapat ditentukan pada permintaan untuk memanfaatkan format isi terstruktur.

Tajuk permintaan Description
Content-Length Dibutuhkan. Harus panjang permintaan yang dikodekan (tidak hanya panjang konten blok).

Jika nilai header tidak cocok dengan panjang yang diharapkan dari permintaan yang dikodekan, operasi gagal dengan kode kesalahan 400 (Permintaan Buruk).
x-ms-structured-body Dibutuhkan. Harus disertakan jika format pesan terstruktur. Nilai header ini berisi versi dan properti skema pesan.

Saat ini, satu-satunya nilai yang didukung adalah XSM/1.0; properties=crc64, yang menunjukkan permintaan menggunakan segmen checksum crc64 dalam pesan yang dikodekan. Jika nilainya tidak cocok dengan ini, operasi gagal dengan kode kesalahan 400 (Permintaan Buruk). Permintaan juga akan gagal jika konten yang disediakan dalam permintaan tidak cocok dengan checksum yang disediakan untuk segmen tertentu.
x-ms-structured-content-length Dibutuhkan. Harus disertakan jika format pesan terstruktur. Nilai header ini adalah panjang konten blok dan akan selalu lebih kecil dari Content-Length nilai header karena pengkodean pesan.

Jika nilai header tidak cocok dengan panjang konten blok yang disediakan dalam permintaan, operasi gagal dengan kode kesalahan 400 (Permintaan Buruk).

Isi dari permintaan

Isi permintaan berisi konten blok.

Permohonan sampel

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=appendblock  HTTP/1.1  
  
Request Headers:  
x-ms-version: 2015-02-21  
x-ms-date: <date>  
x-ms-blob-condition-appendpos: 2097152  
x-ms-blob-condition-maxsize: 4194304  
Authorization: SharedKey myaccount:J4ma1VuFnlJ7yfk/Gu1GxzbfdJloYmBPWlfhZ/xn7GI=  
Content-Length: 1048  
If-Match: "0x8CB172A360EC34B"

Jawaban

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.

Tajuk respons

Respons untuk operasi ini mencakup header berikut. Respons juga dapat menyertakan header HTTP standar tambahan. Semua header standar sesuai dengan spesifikasi protokol HTTP/1.1.

Respons Header Description
ETag Berisi ETag nilai dalam tanda kutip. Klien dapat menggunakan nilai untuk melakukan operasi bersyarat PUT dengan menggunakan header permintaan If-Match .
Last-Modified Tanggal dan waktu gumpalan terakhir diubah. Format tanggal mengikuti RFC 1123. Untuk informasi selengkapnya, lihat Representasi nilai tanggal-waktu dalam header.

Setiap operasi tulis pada blob (termasuk pembaruan pada metadata atau properti blob) mengubah waktu modifikasi terakhir blob.
Content-MD5 Header ini dikembalikan sehingga klien dapat memeriksa integritas konten pesan. Nilai header ini dihitung oleh Blob Storage. Ini 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 Storage. Ini belum tentu nilai yang sama yang ditentukan dalam header permintaan.

Header ini dikembalikan ketika Content-md5 header tidak ada dalam permintaan jika versi sebelum 2026-10-06. Untuk permintaan yang dibuat dengan Versi 2026-10-06 atau lebih baru, header ini akan dikembalikan meskipun Content-MD5 header ada dalam permintaan.
x-ms-request-id Header ini secara unik mengidentifikasi permintaan yang dibuat, dan dapat digunakan untuk memecahkan masalah permintaan.
x-ms-version Menunjukkan versi Blob Storage 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 menunjukkan waktu di mana respons dimulai. Layanan menghasilkan nilai ini.
x-ms-blob-append-offset Header respons ini dikembalikan hanya untuk operasi penambalan. Ini mengembalikan offset di mana blok diterapkan, dalam byte.
x-ms-blob-committed-block-count Jumlah blok yang diterapkan yang ada dalam blob. Anda dapat menggunakan ini untuk mengontrol berapa banyak penambahan lagi yang dapat dilakukan.
x-ms-request-server-encrypted: true/false Versi 2015-12-11 atau lebih baru. Nilai header ini diatur ke true jika konten permintaan berhasil dienkripsi dengan menggunakan algoritme yang ditentukan. Jika tidak, nilainya diatur ke false.
x-ms-encryption-key-sha256 Versi 2019-02-02 atau lebih baru. Header ini dikembalikan jika permintaan menggunakan kunci yang disediakan pelanggan untuk enkripsi. Klien kemudian dapat memastikan konten permintaan berhasil dienkripsi dengan menggunakan kunci yang disediakan.
x-ms-encryption-scope Versi 2019-02-02 atau lebih baru. Header ini dikembalikan jika permintaan menggunakan cakupan enkripsi. Klien kemudian dapat memastikan konten permintaan berhasil dienkripsi dengan menggunakan cakupan enkripsi.
x-ms-client-request-id Anda dapat menggunakan header ini untuk memecahkan masalah permintaan dan respons terkait. Nilai header ini sama dengan nilai x-ms-client-request-id header jika ada dalam permintaan. Nilainya paling banyak 1024 karakter ASCII yang terlihat. Jika x-ms-client-request-id header tidak ada dalam permintaan, header ini tidak ada dalam respons.
x-ms-structured-body Dikembalikan jika permintaan diproses sebagai permintaan isi terstruktur. Nilai header ini sama dengan nilai yang dikirim dalam permintaan, yang saat ini harus .XSM/1.0; properties=crc64

Contoh tanggapan

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Transfer-Encoding: chunked  
x-ms-content-crc64: 77uWZTolTHU  
Date: <date>  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-blob-append-offset: 2097152  
x-ms-blob-committed–block-count: 1000

Authorization

Otorisasi diperlukan saat memanggil operasi akses data apa pun di Azure Storage. Anda dapat mengotorisasi operasi Append Block 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.

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 Append Block, 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

Append Block mengunggah blok ke akhir blob penambahan yang ada. Blok data segera tersedia setelah panggilan berhasil di server. Maksimum 50.000 penambahan diizinkan untuk setiap blob penambahan. Setiap blok dapat memiliki ukuran yang berbeda.

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

Versi layanan Ukuran blok maksimum (melalui)Append Block Ukuran blob maksimum
Versi 2022-11-02 dan yang lebih baru 100 MiB (Pratinjau) Sekitar 4,75 TiB (100 MiB × 50.000 blok)
Versi lebih awal dari 2022-11-02 4 MiB Sekitar 195 gibibyte (GiB) (4 MiB × 50.000 blok)

Append Block berhasil hanya jika blob sudah ada.

Blob yang diupload dengan menggunakan Append Block ID blokir tidak mengeksposisi. Anda tidak dapat memanggil Get Block List terhadap blob penambahan. Melakukannya menghasilkan kesalahan.

Anda dapat menentukan header bersyarat opsional berikut pada permintaan:

  • x-ms-blob-condition-appendpos: Anda dapat mengatur header ini ke offset byte di mana klien mengharapkan untuk menambahkan blok. Permintaan berhasil hanya jika offset saat ini cocok dengan yang ditentukan oleh klien. Jika tidak, permintaan gagal dengan kode kesalahan 412 (Prasyarat Gagal).

    Klien yang menggunakan satu penulis dapat menggunakan header ini untuk menentukan apakah Append Block operasi berhasil, meskipun terjadi kegagalan jaringan.

  • x-ms-blob-condition-maxsize: Klien dapat menggunakan header ini untuk memastikan bahwa operasi penambahan tidak meningkatkan ukuran blob melebihi ukuran maksimum yang diharapkan dalam byte. Jika kondisi gagal, permintaan gagal dengan kode kesalahan 412 (Prakondisi Gagal).

Jika Anda mencoba mengunggah blok yang lebih besar dari ukuran yang diizinkan, layanan akan mengembalikan kode kesalahan 413 (Entitas Permintaan Terlalu Besar). Layanan ini juga mengembalikan informasi tambahan tentang kesalahan dalam respons, termasuk ukuran blok maksimum yang diizinkan dalam byte. Jika Anda mencoba mengunggah lebih dari 50.000 blok, layanan akan menampilkan kode kesalahan 409 (Konflik).

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 kesalahan 412 (Prasyarat Gagal). Jika klien menentukan ID sewa, tetapi blob tidak memiliki sewa aktif, Blob Storage juga mengembalikan kode kesalahan 412.

Jika Anda memanggil Append Block blob blok atau blob halaman yang ada, layanan mengembalikan kesalahan konflik. Jika Anda memanggil Append Block blob yang tidak ada, layanan juga mengembalikan kesalahan.

Hindari penambahan duplikat atau tertunda

Dalam skenario penulis tunggal, klien dapat menghindari penambahan duplikat atau penulisan tertunda dengan menggunakan *x-ms-blob-condition-appendpos header bersyarat untuk memeriksa offset saat ini. Klien juga dapat menghindari duplikat atau penundaan dengan memeriksa secara ETag kondisional, dengan menggunakan If-Match.

Dalam skenario beberapa penulis, setiap klien dapat menggunakan header bersyarat, tetapi ini mungkin tidak optimal untuk performa. Untuk throughput penambahan bersamaan tertinggi, aplikasi harus menangani penambahan redundan dan penambahan tertunda di lapisan aplikasi. Misalnya, aplikasi dapat menambahkan epoch atau nomor urut dalam data yang ditambahkan.

Billing

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

Operasi Jenis akun penyimpanan Kategori penagihan
Tambahkan Blok Objek besar biner blok premium
Standar tujuan umum versi 2
Tujuan umum standar v1		 Operasi tulis

Blok Tambahkan tidak mendukung tingkatan tingkat objek tetapi menyimpulkan tingkat aksesnya dari pengaturan tingkat akses akun default dan ditagih sesuai dengan itu. Untuk mempelajari selengkapnya tentang pengaturan tingkat akun default, lihat Tingkat akses untuk data blob - Azure Storage.

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

  • Last updated on