Perintah dan konteks
Sebuah layanan file harus mentransmisikan byte saat byte tersebut diproduksi, sehingga server tidak mengetahui panjang akhir atau digest saat mengirim header respons. Produk menghendaki klien memverifikasi integritas setelah menerima metadata akhir pesan (end-of-message), tetapi permintaan dapat melewati CDN, reverse proxy, dan berbagai versi HTTP yang berbeda. Rancang kontrak respons, termasuk field mana yang termasuk dalam trailer, cara mendeklarasikan dan memverifikasinya, cara mencatat kegagalan, dan apa yang harus dilakukan ketika klien tidak dapat menerima trailer.
Ini cocok untuk peran backend, gateway, dan infrastruktur. Intinya bukanlah menghafal nama header; melainkan memutuskan apa yang harus diketahui penerima sebelum body dan apa yang hanya dapat diketahui setelah streaming, kemudian membuat penanganan aman terhadap kehilangan pada perantara, pemotongan koneksi (truncation), dan klien yang tidak didukung.
Apa yang sedang diuji oleh pewawancara
Jawaban yang kuat memisahkan digest integritas, tanda tangan (signature), panjang, dan kontrol cache berdasarkan timing, lalu mendeklarasikan field trailer yang diizinkan seperti Trailer: Digest. Jawaban tersebut menjelaskan bahwa pembingkaian chunked HTTP/1.1 hanyalah salah satu mekanisme transport dan bahwa perantara dapat membuang trailer. Klien membedakan antara digest yang hilang, digest yang tidak cocok, dan pesan yang tidak lengkap; berakhirnya koneksi saja bukanlah bukti verifikasi.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Apakah digest ditujukan untuk kerusakan yang tidak disengaja, autentikasi sumber, atau keduanya? Apakah model ancaman mencakup perantara yang berbahaya?
- Apakah klien berupa browser, native SDK, layanan internal, atau klien Node.js yang dapat dikontrol, dan apakah dapat ditingkatkan (di-upgrade)?
- Versi HTTP, CDN, cache, dan lapisan kompresi apa saja yang ada di jalur tersebut, dan mungkinkah mereka melakukan buffering pada respons?
- Bisakah klien mencoba lagi (retry), menggunakan versi objek, permintaan rentang (range requests), atau unduhan yang dapat dilanjutkan (resumable)?
- Haruskah respons dapat di-cache, dan apakah digest mencakup konten yang didekodekan atau representasi yang ditransfer?
Kerangka jawaban 30 detik
"Saya akan mendefinisikan digest sebagai metadata integritas untuk representasi, menggunakan field yang definisinya mengizinkan penggunaan trailer, dan mengirim header Trailer yang menyebutkannya. Server menghitung digest saat melakukan streaming dan memancarkannya di bagian akhir; klien menandai file dapat digunakan hanya setelah pesan selesai dan digest cocok. Karena perantara dapat membuang trailer, saya tidak akan menjadikannya satu-satunya sinyal penting bagi bisnis. Klien yang tidak didukung menggunakan digest yang telah dihitung sebelumnya, manifes yang ditandatangani, atau unduhan baru. Pemotongan koneksi, trailer yang hilang, dan ketidakcocokan adalah status kegagalan yang dapat diamati."
Solusi langkah demi langkah
Langkah 1: tentukan digest dan representasi
Pertama, tentukan byte mana yang dicakup. Biasanya digest ditujukan untuk representasi yang didekodekan; jika server mengirim konten terkompresi, klien harus mengetahui apakah ia memverifikasi byte terkompresi atau byte yang didekodekan. Sertakan algoritma, pengkodean, dan versi objek dalam kontrak sehingga field tersebut memiliki satu makna yang konsisten di seluruh implementasi.
Digest biasa mendeteksi kerusakan yang tidak disengaja tetapi tidak mengautentikasi pengirim. Tanda tangan atau manifes tepercaya diperlukan untuk mencegah penggantian berbahaya. Panjang, perutean, autentikasi, dan kontrol cache yang harus diputuskan sebelum body tidak boleh bergantung pada trailer.
Langkah 2: deklarasikan trailer dan pilih pembingkaian (framing)
HTTP mendefinisikan field trailer sebagai metadata opsional yang diketahui setelah konten dan meminta pengirim untuk mencantumkan nama field yang diantisipasi dalam header Trailer. HTTP/1.1 sering kali membawanya dengan pembingkaian chunked; HTTP/2 memiliki bagian trailer terpisah, sehingga trailer tidak identik dengan chunked encoding.
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Trailer: Digest
Transfer-Encoding: chunked
<streamed bytes>
0
Digest: sha-256=:<base64-value>:Tanda kurung sudut adalah placeholder dan tetap berada di dalam blok kode berpagar. Kontrak produksi menggunakan sintaks field terdaftar yang secara eksplisit mengizinkan trailer. Jangan menciptakan field arbitrer dan berasumsi setiap perantara akan meneruskannya.
Langkah 3: tentukan state machine klien
Status klien harus mencakup reading, complete-awaiting-trailer, verified, missing-trailer, mismatch, dan truncated. Berikan file yang dapat digunakan hanya setelah body dan pesan selesai serta digest cocok. Koneksi tertutup tanpa pesan lengkap adalah pemotongan (truncation).
Fetch di browser, SDK seluler, dan layanan internal mengekspos trailer secara berbeda. Token permintaan TE: trailers hanya menunjukkan kesediaan untuk mempertahankan bagian trailer; ini tidak menjanjikan pemrosesan field tertentu. Untuk klien yang tidak dapat dikontrol, digest objek yang telah dihitung sebelumnya atau manifes lebih dapat diandalkan.
Langkah 4: tangani perantara dan cache
RFC 9110 memperingatkan bahwa perantara dapat membuang trailer dan dapat melakukan buffering atau mengubahnya saat meneruskan antar versi HTTP. Pengujian kompatibilitas untuk CDN atau proxy harus memeriksa retensi deklarasi, retensi trailer sebenarnya, perilaku digest setelah kompresi, dan respons cache-hit.
Kunci cache harus menyertakan versi objek dan pengkodean representasi. Jika cache tidak mempertahankan trailer, hit tidak dapat mengklaim bahwa klien telah memverifikasi konten. Simpan manifes di lapisan cache atau gunakan field Digest atau tanda tangan yang telah dihitung sebelumnya sebagai gantinya.
Langkah 5: tangani kegagalan dan percobaan ulang (retry)
Digest yang hilang bukanlah digest yang cocok, dan penutupan awal bukanlah digest kosong. Klien menyimpan alasan, versi objek, dan jumlah byte yang diterima; layanan mencatat ID permintaan, durasi, dan ringkasan jalur perantara. Coba lagi dengan permintaan rentang atau versi objek baru jika aman, dan jangan pernah memublikasikan file parsial yang rusak sebagai berhasil.
Jika server mengalami crash sebelum menghitung atau mengirim trailer, server tidak boleh mengarang respons 200 normal. Downstream dapat mengarantina objek yang belum diverifikasi hingga unduhan baru atau manifes tepercaya memverifikasinya.
Langkah 6: pilih kontrak fallback
Untuk file kecil, hitung digest sebelumnya dan letakkan di field respons biasa. Untuk file besar, publikasikan manifes bertanda tangan yang berisi versi objek, panjang, digest, dan masa kedaluwarsa. Unggahan multipart dan penyimpanan objek sering kali sudah menyediakan checksum bagian; layanan metadata dapat mengekspos digest akhir tanpa membuat penerimaan bergantung pada trailer.
Jadikan fallback eksplisit dalam kontrak unduhan yang sama: klien melaporkan verified-by-trailer, verified-by-manifest, atau unverified. Jangan mencampur status ini secara diam-diam.
Langkah 7: izin, tanda tangan, dan privasi
Digest biasanya tidak sensitif, tetapi nama objek, versi, dan metadata tanda tangan dapat mengungkapkan keberadaan sumber daya. Otorisasi respons manifes per objek, simpan kunci penandatanganan di sisi server, dan distribusikan kunci verifikasi melalui konfigurasi tepercaya. Jangan pernah memasukkan token pengguna, jalur internal, atau stack trace ke dalam trailer.
Untuk tanda tangan, tetapkan byte yang dicakup, kanonikalisasi, dan aturan kedaluwarsa. Rekompresi atau transcoding mengubah byte yang ditandatangani, jadi tentukan apakah tanda tangan mencakup versi sumber daya atau representasi konkret.
Langkah 8: verifikasi dan amati
Uji matriks klien yang dapat dikontrol dan perantara nyata: HTTP/1.1 chunked, HTTP/2, kompresi, cache hit, trailer yang dibuang, pemotongan, digest yang salah, field duplikat, dan backpressure pada file besar. Node.js mendokumentasikan bahwa response.addTrailers() memerlukan header Trailer dan bahwa respons non-chunked dapat membuang trailer secara diam-diam; kondisi tersebut harus dimasukkan dalam assertion integrasi.
Lacak tingkat digest yang hilang, tingkat ketidakcocokan, tingkat pemotongan, keberhasilan percobaan ulang, versi perantara, dan latensi verifikasi. Peringatan harus membedakan satu klien yang tidak didukung dari jalur CDN yang secara sistematis membuang trailer, alih-alih menyebut setiap penurunan kompatibilitas sebagai kerusakan konten.
Trade-off dan batasan
Trailer cocok untuk integritas atau metadata pascapemrosesan yang hanya diketahui setelah pembuatan, memungkinkan file di-stream tanpa melakukan buffering terlebih dahulu untuk menghitung digest. Kelemahannya adalah dukungan yang tidak konsisten pada klien dan perantara, dan trailer tidak dapat membawa semantik perutean, autentikasi, panjang, atau cache yang harus diputuskan sebelum body.
Digest dan manifes yang telah dihitung sebelumnya lebih mudah di-cache, dicoba ulang, dan diverifikasi di seluruh klien, tetapi menambah pembacaan metadata dan sinkronisasi versi. Tanda tangan memberikan jaminan sumber yang lebih kuat daripada digest, dengan konsekuensi biaya rotasi kunci, kanonikalisasi, dan pengelolaan masa kedaluwarsa. Pilihlah berdasarkan latensi pembuatan, kontrol klien, jalur perantara, dan model ancaman.
Rencana peluncuran dan bukti
Aktifkan trailer terlebih dahulu di SDK internal dan satu jalur CDN, ukur retensi dan hasil verifikasi. Sediakan fallback manifes dan buat klien melaporkan mode verifikasi mereka. Setelah pengujian HTTP/1.1, HTTP/2, kompresi, dan cache berhasil, perluas ke klien yang tidak dapat dikontrol; jika jalur kritis membuang trailer, jadikan manifes sebagai jalur yang wajib.
RFC 9110 menjelaskan trailer untuk pemeriksaan integritas, tanda tangan, dan status pascapemrosesan, sekaligus menetapkan deklarasi, batasan, dan perilaku kehilangan pada perantara. Node.js mendokumentasikan kondisi pengiriman untuk Trailer dan addTrailers(). Panduan wawancara REST API publik menekankan kontrak, idempoten, kesalahan, dan observabilitas. Bersama-sama, hal tersebut mendukung pilihan protokol dan rencana verifikasi dalam pertanyaan ini.
Kesalahan umum dan tindak lanjut
Memperlakukan trailer sebagai "header respons yang terlambat"
Waktu pemrosesan dan semantik perantara berbeda. Hanya metadata yang definisi field-nya mengizinkan trailer yang termasuk di sana, dan itu harus disimpan serta diproses secara terpisah.
Menghilangkan header Trailer
Banyak implementasi tidak akan memancarkan atau mengekspos field trailing secara andal. Deklarasikan nama field terlebih dahulu, lalu uji retensi sebenarnya dengan klien dan proxy.
Hanya memeriksa bahwa koneksi telah ditutup
Penutupan bisa berarti pemotongan (truncation). Konfirmasikan kelengkapan pesan, keberadaan trailer, dan kecocokan digest sebelum mengirimkan file.
Menyebut digest sebagai tanda tangan
Digest mendeteksi kerusakan yang tidak disengaja tetapi tidak dapat menghentikan penyerang dengan akses tulis untuk mengganti konten. Gunakan manifes bertanda tangan dan distribusi kunci tepercaya untuk autentikasi.
Bagaimana jika CDN membuang trailer?
Biarkan objek tidak terverifikasi, beralihlah ke digest atau manifes yang telah dihitung sebelumnya, dan pantau tingkat pembuangan jalur tersebut. Jangan pernah mengubah digest yang hilang menjadi keberhasilan secara diam-diam.