Petunjuk dan konteks
Pertanyaan backend ini menguji respons parsial HTTP, pembacaan object-store, dan state machine pengunduhan. Tantangannya bukan meneruskan header ke penyimpanan; melainkan menjaga agar rentang (range), versi entitas, encoding, izin, dan segmen konkuren tetap konsisten saat terjadi kegagalan dan percobaan ulang (retry).
Hal yang dievaluasi pewawancara
- Apakah Anda mengurai satu rentang byte dan menyusun 206, Content-Range, Content-Length, dan Accept-Ranges dengan benar.
- Apakah ETag atau Last-Modified dengan If-Range mencegah klien menggabungkan versi file yang berbeda.
- Apakah rentang tidak valid, tanda tangan kedaluwarsa, objek yang dihapus, batas laju (rate limits), dan biaya multi-range ditangani.
- Apakah integritas, observabilitas, dan otorisasi mencegah endpoint menjadi pembaca objek arbitrer.
Pertanyaan klarifikasi yang perlu diajukan
Konfirmasikan apakah objek bersifat publik, ukuran maksimum, apakah respons multi-range diperlukan, apakah penyimpanan mendukung rentang native, apakah kompresi diizinkan, dan apakah klien mempertahankan ETag. Tanyakan tentang masa aktif URL, konkurensi segmen, algoritma integritas, dan perilaku produk saat versi sumber daya berubah.
Kerangka jawaban 30 detik
Saya akan mengotorisasi permintaan dan mengunci (pin) versi objek, lalu membaca ukuran, ETag, dan metadata media. Tanpa Range akan mengembalikan 200; satu rentang yang dapat dipenuhi mengembalikan 206 dengan Content-Range yang tepat; rentang yang salah format atau tidak dapat dipenuhi mengembalikan 416 dengan panjang saat ini. Ketidakcocokan If-Range menyebabkan respons penuh untuk versi saat ini sehingga klien memulai ulang. Setiap segmen dibatasi laju dan konkurensinya, dan respons maupun file akhir diperiksa terhadap versi dan checksum.
Pembahasan mendalam langkah demi langkah
1. Kunci representasi dan batas otorisasi
Otorisasi berdasarkan pengguna, tenant, dan ID objek; jangan pernah memetakan path klien arbitrer secara langsung ke kunci penyimpanan. Baca metadata objek dan kunci pengidentifikasi versi, total byte, Content-Type, Content-Encoding, dan ETag. Jika objek berubah, gunakan penyimpanan immutable atau berversi sehingga metadata dan byte tidak bergeser selama satu proses pengunduhan.
2. Urai rentang dan buat respons
Dukung satu rentang bytes=start-end, bytes=start-, atau bytes=-suffix, dengan memvalidasi bilangan bulat, overflow, dan panjang total. Setelah membatasi (clamping) rentang yang dapat dipenuhi ke representasi, kembalikan 206, Content-Range, dan panjang yang tepat. Tanpa Range kembalikan 200. Jika tidak ada rentang yang dapat dipenuhi, kembalikan 416 dengan Content-Range: bytes */total. Permintaan multi-range memerlukan pilihan eksplisit: tolak, bagi menjadi permintaan terbatas, atau terapkan multipart; jangan pernah mengembalikan bagian pertama secara diam-diam.
3. Tangani If-Range dan pengkodean konten
Hormati ETag kuat atau tanggal dalam If-Range hanya jika masih cocok dengan representasi yang dipilih; jika tidak, abaikan Range dan kirim representasi lengkap saat ini. Rentang mengacu pada byte dari representasi yang sebenarnya ditransfer. Jangan memotong byte terkompresi dan meminta klien untuk menggabungkannya seolah-olah itu adalah file yang tidak dikompresi. Nonaktifkan kompresi dinamis atau berikan setiap encoding versi dan checksum independen.
4. Batasi konkurensi, biaya, dan pemulihan
Batasi segmen per pengguna, tenant, dan objek, ditambah total bandwidth dan ukuran rentang minimum, untuk mencegah banyak permintaan kecil melipatgandakan biaya penyimpanan. Coba ulang segmen yang gagal hanya dengan versi dan rentang yang sama. Jika URL bertanda tangan kedaluwarsa, terbitkan URL baru tanpa mengubah versi. Penghapusan objek atau perubahan izin akan menghentikan segmen berikutnya, dan klien membuang file yang tidak lengkap alih-alih menggabungkannya secara diam-diam.
5. Verifikasi integritas dan amati perilaku
Setelah mengunduh, verifikasi versi objek, panjang total, dan checksum; untuk data berisiko tinggi, verifikasi setiap segmen sebelum digabungkan. Catat rentang yang dinormalisasi, versi, status, byte, latensi penyimpanan, cache hit, dan jumlah percobaan ulang tanpa mencatat kredensial unduhan. Uji rentang kosong, sufiks, overflow, pembaruan objek, percobaan ulang konkuren, resume offline, dan setiap Content-Encoding untuk membuktikan bahwa 206 tidak pernah menyajikan versi yang salah.
Contoh jawaban yang kuat
Setelah otorisasi, saya mengunci versi objek yang immutable dan mengekspos ukuran, ETag, tipe, serta encoding-nya. Rentang tunggal bytes yang dapat dipenuhi mengembalikan 206 dengan Content-Range dan Content-Length; tanpa rentang mengembalikan 200; rentang yang tidak dapat dipenuhi mengembalikan 416 dengan bytes */total. Ketidakcocokan If-Range mengabaikan Range dan mengirimkan versi lengkap saat ini, mencegah file tercampur. Batasan konkurensi, laju, dan rentang minimum per pengguna serta per objek mengendalikan biaya, dan percobaan ulang mempertahankan versi yang sama. Klien memverifikasi panjang, versi, dan checksum; server mengamati rentang, status, latensi penyimpanan, dan percobaan ulang.
Kesalahan umum
- Meneruskan Range tanpa memeriksa otorisasi, versi objek, atau integer overflow.
- Mengembalikan 200 atau body kosong untuk rentang yang tidak dapat dipenuhi alih-alih 416.
- Mengabaikan If-Range dan membiarkan pembaruan membuat file dengan versi tercampur.
- Menerapkan koordinat rentang ke byte terkompresi yang kemudian diperlakukan oleh klien sebagai data tidak terkompresi.
- Mengizinkan segmen kecil dan konkurensi tanpa batas, mengubah satu unduhan menjadi lonjakan beban penyimpanan (storage storm).
- Hanya memeriksa kode status alih-alih panjang total, ETag, dan checksum akhir.
Pertanyaan lanjutan dan jawaban
Mengapa tidak selalu mengembalikan 206?
Tanpa Range, klien meminta representasi penuh, sehingga 200 adalah respons yang tepat. Bahkan dengan Range, server harus memeriksa keterpenuhannya; 416 memberi tahu klien panjang saat ini sehingga klien dapat memperbaiki permintaan.
Apa perbedaan If-Range dengan If-Match?
If-Range menentukan apakah transfer parsial dapat dilanjutkan: kecocokan menghasilkan 206 dan ketidakcocokan menghasilkan representasi penuh. If-Match adalah prasyarat untuk melakukan operasi target, sehingga kegagalannya memiliki arti yang berbeda.
Apa yang harus Anda lakukan dengan permintaan multi-range?
Pertama, konfirmasikan apakah klien dan penyimpanan membutuhkannya. Bagi menjadi permintaan terbatas atau terapkan multipart/byteranges; jika biayanya tidak sebanding, tolak secara eksplisit daripada mengembalikan rentang pertama dan menciptakan ambiguitas.
Bagaimana Anda mencegah tautan unduhan bertanda tangan disalahgunakan?
Gunakan tanda tangan berumur pendek yang terikat pada pengguna, tenant, objek, versi, dan izin. Periksa kembali batasan di sisi server dan batasi konkurensi, laju, jumlah rentang, serta total byte. Akses yang dicabut atau penghapusan harus membatalkan permintaan rentang berikutnya.