Konteks dan cakupan
Klien mengunggah file berukuran beberapa ratus megabita ke penyimpanan objek (object storage). Server dapat menolak token yang tidak valid, kuota, atau tipe media hanya dengan menggunakan header permintaan. Rancang handshake pengunggahan HTTP/1.1 dan jelaskan Expect: 100-continue, fallback 417, hop proxy, timeout, percobaan ulang (retry), serta metrik.
Ini adalah pertanyaan protokol backend dan keandalan. Ukuran file dan status adalah asumsi untuk latihan ini, bukan klaim frekuensi.
Apa yang diuji oleh pewawancara
- Apakah Anda memisahkan penerimaan (admission) hanya-header dari pemrosesan body.
- Apakah Anda menjelaskan 100, respons akhir, dan 417 secara tepat.
- Apakah Anda menangani ekspektasi yang diabaikan, batas waktu tunggu (wait timeout), dan penggunaan kembali koneksi (connection reuse).
- Apakah percobaan ulang, idempotensi, checksum, dan observabilitas memiliki penanggung jawab yang jelas.
Pertanyaan klarifikasi yang perlu diajukan
- Apakah proses unggah bersifat idempoten, dan apakah ada sesi unggah atau kunci idempotensi?
- Bisakah klien memutar kembali (rewind) sumber body dan membuka kembali file tersebut?
- Gateway dan layanan penyimpanan mana yang mempertahankan respons informasional?
- Bisakah upaya yang gagal dicoba ulang tanpa Expect, dan mungkinkah itu membuat duplikat?
- Aturan mana yang merupakan pemeriksaan hanya-header, dan mana yang memerlukan pembacaan seluruh body?
Jawaban 30 detik
“Klien mengirimkan header dengan Expect: 100-continue. Server memeriksa autentikasi, panjang, tipe, kuota, dan perutean; server mengirimkan 4xx final untuk penolakan langsung atau 100 Continue ketika siap menerima body. Klien mengirimkan body hanya setelah respons sementara, dengan batas waktu tunggu tertentu. Respons 417 dapat memicu percobaan ulang tanpa Expect hanya jika body dapat di-rewind dan operasi aman untuk diulang. Saya mempertahankan kunci idempotensi yang sama dan mengukur perilaku proxy, byte yang dihemat, tingkat 417, dan body yang dibatalkan.”
Desain langkah demi langkah
1. Kirim header terlebih dahulu
Permintaan membawa autentikasi, Content-Length, Content-Type, digest, informasi tenant, kunci idempotensi, dan Expect: 100-continue. Sebelum membaca body, server dapat memeriksa token, rute, kuota, dan batas ukuran statis. Spesifikasi mewajibkan respons setelah keputusan diambil; klien tidak boleh menunggu tanpa batas waktu.
PUT /objects/o-123 HTTP/1.1
Host: upload.example
Authorization: Bearer ...
Content-Length: 524288000
Content-Type: application/octet-stream
Idempotency-Key: up-7f2
Expect: 100-continue2. Tangani penerimaan dan penolakan
Untuk penerimaan, kembalikan 100 Continue, lalu terima body. Untuk autentikasi yang tidak valid, panjang berlebih, atau kuota tidak mencukupi, kembalikan status akhir seperti 401, 403, 413, atau 415; klien tidak boleh mengirim byte body yang belum dikirimnya. Preflight hanya mencakup aturan yang terlihat pada header, sehingga hasil akhir tetap bergantung pada validasi body.
3. Gunakan 417 secara spesifik
417 Expectation Failed berarti server atau perantara tidak dapat memenuhi ekspektasi. Jika operasi mengizinkannya, klien dapat menghapus Expect dan mengirim ulang, tetapi klien harus dapat memutar kembali (rewind) body, mempertahankan kunci idempotensi, dan memastikan koneksi lama tidak memiliki body yang belum terbaca. Jangan memperlakukan setiap 4xx sebagai 417 atau mengulang pekerjaan non-idempoten yang tidak dapat dibatalkan.
4. Perhitungkan waktu tunggu, proxy, dan koneksi
Klien memberikan batas waktu tertentu untuk menunggu 100 dan mencatat jalur timeout. Perantara HTTP/1.0 mungkin mengabaikan Expect, dan proxy dapat menghasilkan 100 sendiri. Uji setiap hop untuk penerusan header, penanganan respons informasional, dan apakah penolakan akhir menutup atau menguras (drain) koneksi; jika tidak, sisa byte dapat merusak penggunaan kembali koneksi.
5. Buat percobaan ulang menjadi idempoten
Coba lagi hanya jika sumber body dapat di-rewind dan operasi bisnis mengizinkan pengulangan. Pembuatan objek atau pengurangan kuota harus menggunakan kunci idempotensi yang stabil sehingga percobaan terpetakan ke satu hasil. Setelah diskoneksi, hasilnya mungkin tidak diketahui; kueri sesi unggahan atau status objek sebelum membuat objek lain.
6. Validasi di kedua fase
Pemeriksaan preflight mencakup autentikasi, tenant, panjang, tipe, dan kuota. Setelah menerima body, validasi jumlah byte sebenarnya, digest, konten berbahaya, dan kebijakan penyimpanan. Jangan hanya memercayai Content-Length atau tipe MIME yang dideklarasikan klien. Catat ID permintaan, hasil penerimaan, dan byte yang diterima dalam log, jangan pernah mencatat token atau konten file.
Contoh jawaban berkualitas tinggi
“Saya membagi proses unggah menjadi keputusan header dan penyerapan body. Klien mengirim autentikasi, panjang, tipe, digest, kunci idempotensi, dan Expect: 100-continue. Server menolak kegagalan yang murah dan deterministik sebelum body; setelah penerimaan, server mengirim 100 dan klien mengunggah. Respons 417 menyebabkan percobaan ulang tanpa Expect hanya jika pemutaran ulang aman, dengan kunci idempotensi yang sama. Timeout waktu tunggu, diskoneksi, dan perilaku proxy dipulihkan melalui kueri status. Ukuran body, digest, dan keamanan konten tetap divalidasi. Saya menguji latensi 100, 417, 4xx dini, penggunaan kembali koneksi, dan byte yang dihemat di seluruh proxy nyata.”
Kesalahan umum
- Menganggap 100 sebagai keberhasilan → ini hanya mengizinkan body → tunggu 2xx final atau kegagalan.
- Mencoba ulang tanpa Expect setelah 4xx apa pun → efek samping dapat terduplikasi → fallback hanya untuk 417 dan pemutaran ulang yang aman.
- Menunggu 100 selamanya → permintaan menggantung → batasi dan pantau waktu tunggu.
- Hanya memeriksa header → body yang rusak atau berbahaya masuk ke penyimpanan → validasi juga setelah penyerapan.
- Mengabaikan perbedaan proxy → body dini atau sisa byte merusak penggunaan kembali → uji setiap hop dan kendalikan penggunaan kembali koneksi.
Pertanyaan lanjutan dan tanggapan
Bagaimana jika klien mengirim byte body sebelum menerima 401?
Server mengikuti kebijakan koneksinya untuk menutup atau melanjutkan membaca dan membuang body. Klien berhenti mengirim dan menandai upaya tersebut gagal. Penggunaan kembali koneksi memerlukan bukti bahwa status protokol telah selaras kembali.
Mengapa tidak selalu mengirim body secara langsung?
Permintaan kecil mungkin tidak sebanding dengan handshake ini. Permintaan besar diuntungkan ketika kegagalan autentikasi, panjang, atau kuota dapat dideteksi lebih awal. Terapkan berdasarkan ukuran permintaan, kompatibilitas proxy, dan biaya implementasi.
Apakah ide ini masih penting untuk HTTP/2 atau HTTP/3?
Jangan menganggap perilaku tingkat byte identik. Verifikasi bagaimana klien, gateway, dan server yang dipilih menangani respons informasional, kontrol aliran (flow control), dan pembatalan stream. Tujuan utamanya tetap sama: penolakan dini, status unggahan yang dapat dipulihkan, dan idempotensi.