Tambahkan Blok Dari URL

Artikel
02/03/2024

Operasi ini Append Block From URL menerapkan blok data baru ke akhir blob penambahan yang ada.

Operasi Append Block From URL hanya diizinkan jika blob dibuat dengan x-ms-blob-type diatur ke AppendBlob. Append Block From URL hanya didukung pada versi 2018-11-09 atau yang lebih baru.

Minta

Anda dapat membuat Append Block From URL permintaan 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 ditimulasi, tentukan nama host emulator dan port Azure Blob Storage 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=appendblock`	HTTP/1.1

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

Parameter URI

Parameter	Deskripsi
`timeout`	Opsional. Parameter batas waktu dinyatakan dalam hitung detik. Untuk informasi selengkapnya, lihat Mengatur batas waktu untuk operasi Blob Storage.

Header permintaan

Tabel berikut ini menjelaskan header permintaan yang diperlukan dan opsional.

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 layanan Azure Storage.
`Content-Length`	Wajib diisi. Menentukan jumlah byte yang dikirimkan dalam isi permintaan. Nilai header ini harus diatur ke nol. Ketika panjangnya bukan nol, operasi akan gagal dengan kode kesalahan 400 (Permintaan Buruk).
`x-ms-copy-source:name`	Wajib diisi. 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 publik atau harus diotorisasi melalui tanda tangan akses bersama. Jika blob sumber bersifat publik, tidak ada otorisasi yang diperlukan 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>`	Opsional. 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 ID. Header ini didukung dalam versi 2020-10-02 dan yang lebih baru.
`x-ms-source-range`	Pilihan. Hanya mengunggah byte blob di URL sumber dalam rentang yang ditentukan. Jika ini tidak ditentukan, seluruh konten blob sumber diunggah sebagai satu blok penambahan. Lihat Menentukan header rentang untuk operasi Blob Storage untuk informasi selengkapnya.
`x-ms-source-content-md5`	Pilihan. Hash MD5 dari konten blok penambahan dari URI. Hash ini digunakan untuk memverifikasi integritas blok penambahan selama pengangkutan data dari URI. Saat Anda menentukan header ini, layanan penyimpanan membandingkan hash konten yang telah tiba dari sumber salin dengan nilai header ini. Perhatikan bahwa hash MD5 ini tidak disimpan dengan blob. Jika dua hash tidak cocok, operasi gagal dengan kode kesalahan 400 (Permintaan Buruk).
`x-ms-source-content-crc64`	Pilihan. Hash CRC64 dari konten blok penambahan dari URI. Hash ini digunakan untuk memverifikasi integritas blok penambahan selama pengangkutan data dari URI. Saat Anda menentukan header ini, layanan penyimpanan membandingkan hash konten yang telah tiba dari sumber salin dengan nilai header ini. Perhatikan bahwa hash CRC64 ini tidak disimpan dengan blob. Jika dua hash tidak cocok, operasi gagal dengan kode kesalahan 400 (Permintaan Buruk). Jika header `x-ms-source-content-md5` dan `x-ms-source-content-crc64` ada, permintaan gagal dengan 400 (Permintaan Buruk). Header ini didukung dalam versi 2019-02-02 atau yang lebih baru.
`x-ms-encryption-scope`	Pilihan. Menunjukkan cakupan enkripsi yang akan digunakan untuk mengenkripsi konten sumber. 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`	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.
`x-ms-blob-condition-maxsize`	Header bersyar opsional. Panjang maksimum dalam byte yang diizinkan untuk blob penampan. `Append Block From URL` Jika operasi menyebabkan blob melebihi batas tersebut, atau jika ukuran blob sudah lebih besar dari nilai yang ditentukan di header ini, permintaan gagal dengan 412 (Prasyarat Gagal).
`x-ms-blob-condition-appendpos`	Header bersyarah opsional, hanya digunakan untuk `Append Block from URL` operasi. Angka yang menunjukkan offset byte untuk dibandingkan. `Append Block from URL` hanya berhasil jika posisi penampan sama dengan angka ini. Jika tidak, permintaan gagal dengan 412 (Prasyarat Gagal).

Operasi ini mendukung penggunaan header bersyarat tambahan, untuk memastikan bahwa API hanya berhasil jika kondisi tertentu terpenuhi. Untuk informasi selengkapnya, lihat Menentukan header kondisional untuk operasi 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 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=appendblock  HTTP/1.1  

Request Headers:  
x-ms-version: 2018-11-09  
x-ms-date: <date>  
x-ms-copy-source: https://myaccount.blob.core.windows.net/mycontainer/myblob
x-ms-source-range: bytes=0-65535
x-ms-blob-condition-appendpos: 2097152  
x-ms-blob-condition-maxsize: 4194304  
Authorization: SharedKey myaccount:J4ma1VuFnlJ7yfk/Gu1GxzbfdJloYmBPWlfhZ/xn7GI=  
Content-Length: 0 
If-Match: "0x8CB172A360EC34B"

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 Kode status dan 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
`Etag`	`ETag` berisi nilai dalam tanda kutip. Klien menggunakan nilai untuk melakukan operasi kondisional `PUT` dengan menggunakan `If-Match` header permintaan.
`Last-Modified`	Tanggal/waktu blob terakhir diubah. Format tanggal mengikuti RFC 1123. Untuk informasi selengkapnya, lihat Representasi nilai tanggal-waktu di header. Setiap operasi tulis pada blob (termasuk pembaruan pada metadata atau properti blob) mengubah waktu blob yang terakhir dimodifikasi.
`Content-MD5`	Header ini dikembalikan sehingga klien dapat memeriksa integritas konten pesan. Blob Storage menghitung nilai header ini. 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. Blob Storage menghitung nilai header ini. Ini belum tentu nilai yang sama yang ditentukan dalam header permintaan. Header ini dikembalikan ketika `x-ms-source-content-md5` header tidak 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 dihasilkan oleh layanan yang menunjukkan waktu dimulainya respons.
`x-ms-blob-append-offset`	Header respons ini dikembalikan hanya untuk operasi penampingan. 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 tambahan yang dapat dilakukan.
`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 dengan menggunakan algoritma yang ditentukan. Jika tidak, nilai diatur ke `false`.
`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. Klien kemudian dapat memastikan bahwa konten permintaan berhasil dienkripsi dengan menggunakan kunci yang disediakan.
`x-ms-encryption-scope`	Versi 2019-02-02 atau yang lebih baru. Header ini dikembalikan jika permintaan menggunakan cakupan enkripsi. Klien kemudian dapat memastikan bahwa konten permintaan berhasil dienkripsi dengan menggunakan cakupan enkripsi.

Respons sampel

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 seperti yang Append Block From URL dijelaskan di bawah ini.

Detail otorisasi di bagian ini berlaku untuk tujuan salin. Untuk informasi selengkapnya tentang otorisasi sumber salin, lihat detail untuk header x-ms-copy-sourcepermintaan .

Penting

Microsoft merekomendasikan penggunaan Microsoft Entra ID 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 Microsoft Entra ID 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. Perwakilan keamanan mungkin pengguna, grup, perwakilan layanan aplikasi, atau identitas terkelola Azure. Perwakilan 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 Microsoft Entra ID, lihat Mengotorisasi akses ke blob menggunakan Microsoft Entra ID.

Izin

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

Tindakan Azure RBAC:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action atau 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.

Tanda tangan akses bersama (SAS) menyediakan akses yang didelegasikan dengan 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 Append Block From URL 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 selengkapnya, lihat Memahami bagaimana melarang Kunci Bersama memengaruhi token SAS.

Delegasi pengguna SAS

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

Memanggil Append Block From URL operasi menggunakan token SAS yang didelegasikan ke kontainer atau sumber daya blob memerlukan izin Tambahkan (a) atau Tulis (w) sebagai bagian dari token SAS delegasi pengguna:

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

Layanan SAS

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

Untuk mempelajari selengkapnya tentang layanan SAS, lihat Create 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 ditentukan saat mendelegasikan akses:

Operasi	Layanan yang ditandatangani	Jenis sumber daya yang ditandatangani	Izin yang ditandatangani
Tambahkan Blok Dari URL	Blob (b)	Objek (o)	Tambahkan (a) atau Tulis (w)

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

Keterangan

Append Block From URL mengunggah blok ke akhir blob penambahan yang ada. Blok data segera tersedia setelah panggilan berhasil di server. Maksimum 50.000 tambahan diizinkan untuk setiap blob penampingan, di mana. 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 From URL`)	Ukuran blob maksimum
Versi 2022-11-02 dan yang lebih baru	100 MiB (Pratinjau)	Sekitar 4,75 TiB (100 MiB × 50.000 blok)
Versi yang lebih lama dari 2022-11-02	4 MiB	Sekitar 195 gibibyte (GiB) (4 MiB × 50.000 blok)

Dalam versi 2020-10-02 dan yang lebih baru, Microsoft Entra ID otorisasi didukung untuk sumber operasi salin.

Append Block From URL berhasil hanya jika blob sudah ada.

Blob yang diunggah dengan menggunakan Append Block From URL jangan mengekspos ID blok, sehingga Anda tidak dapat memanggil Dapatkan Daftar Blokir terhadap blob penambahan. Melakukannya menghasilkan kesalahan.

Anda dapat menentukan header opsional dan kondisional berikut pada permintaan:

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

Klien yang menggunakan penulis tunggal dapat menggunakan header ini untuk menentukan apakah operasi Append Block From URL berhasil, meskipun terjadi kegagalan jaringan.
x-ms-blob-condition-maxsize: Klien dapat menggunakan header ini untuk memastikan bahwa operasi penambahan tidak meningkatkan ukuran blob di luar ukuran maksimum yang diharapkan dalam byte. Jika kondisi gagal, permintaan gagal dengan kode kesalahan 412 (Prasyarat Gagal).

Jika Anda mencoba mengunggah blok yang lebih besar dari ukuran yang diizinkan, layanan mengembalikan kode kesalahan HTTP 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 mengembalikan 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, layanan mengembalikan kode kesalahan 412.

Jika Anda memanggil Append Block From URL blob blok atau blob halaman yang ada, layanan mengembalikan kode kesalahan 409 (Konflik). Jika Anda memanggil Append Block From URL blob yang tidak ada, layanan mengembalikan kode kesalahan 404 (Tidak Ditemukan).

Hindari penambah duplikat atau tertunda

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

Dalam beberapa skenario penulis, setiap klien dapat menggunakan header kondisional. Ini mungkin tidak optimal untuk performa. Untuk throughput tambahan bersamaan tertinggi, aplikasi harus menangani pelengkap redundan dan pelengkap yang tertunda di lapisan aplikasi mereka. Misalnya, aplikasi dapat menambahkan epoch atau nomor urutan dalam data yang ditambahkan.

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

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 Append Block From URL permintaan berdasarkan jenis akun penyimpanan:

Operasi	Jenis akun penyimpanan	Kategori penagihan
Tambahkan Blok Dari URL (akun tujuan¹)	Objek besar biner blok premium Tujuan umum standar v2 Tujuan umum standar v1	Operasi tulis
Tambahkan Blok Dari URL (akun sumber²)	Objek besar biner blok premium Tujuan umum standar v2 Tujuan umum standar v1	Membacakan operasi

¹Akun tujuan dibebankan untuk satu transaksi untuk memulai penulisan.
²Akun sumber menimbulkan satu transaksi untuk setiap permintaan baca ke sumbernya.

Bagikan melalui