1. Petunjuk dan konteks
Sebuah API multi-tenant HTTPS menggunakan ulang koneksi HTTP/2 di beberapa domain. Beberapa permintaan sesekali menerima 421, dan tim ingin menulis ulangnya menjadi 503 di controller aplikasi. Nilai semantik dari 421, jelaskan perbandingan SNI dengan Host, dan rancang rencana untuk gateway, origin, klien, serta observabilitas. Asumsikan permintaan dapat melewati CDN, reverse proxy, dan service mesh.
2. Apa yang sedang diuji oleh pewawancara
- Apakah Anda mengetahui bahwa 421 berarti permintaan telah mencapai origin yang tidak dapat atau tidak bersedia memberikan respons otoritatif untuk URI target.
- Apakah Anda dapat menghubungkan penggunaan ulang koneksi, TLS SNI, Host permintaan, skema, dan authority dalam satu rantai diagnostik.
- Apakah Anda memahami bahwa proxy tidak boleh membuat status 421 dari keputusan peruteannya sendiri dan bahwa klien hanya boleh mencoba ulang pada koneksi baru.
- Apakah Anda dapat memisahkan 421 dari kegagalan upstream, 404, 503, dan kesalahan konfigurasi sertifikat daripada hanya mengubah kode statusnya.
3. Pertanyaan klarifikasi sebelum menjawab
- Apakah 421 dihasilkan oleh origin, gateway, CDN, atau aplikasi?
- Apakah permintaan menggunakan HTTP/2 atau HTTP/3, dan dapatkah satu koneksi membawa banyak authority?
- Apa TLS SNI, HTTP Host, dan virtual host yang dipilih pada hop terakhir?
- Dapatkah klien membuka koneksi baru untuk domain target, dan apakah metodenya idempoten atau sudah menimbulkan efek samping (side-effecting)?
4. Kerangka jawaban 30 detik
421 berarti origin meyakini bahwa permintaan diarahkan ke koneksi atau virtual host yang salah, seperti kombinasi sertifikat koneksi dan authority target yang tidak kompatibel. Diagnosis SNI, Host, skema, authority, connection pooling, dan perutean origin sebelum mengubah respons; jangan menulis ulang menjadi 503. Origin boleh mengirimkan 421, sedangkan proxy harus meneruskannya daripada membuatnya sendiri dari keputusan peruteannya. Klien dapat mencoba ulang pada koneksi baru, bergantung pada idempotensi metode, kemampuan pengulangan body permintaan (request-body replay), dan backoff. Hubungkan ID koneksi, SNI, authority, rute, dan hasil percobaan ulang dalam log.
5. Jawaban mendalam langkah demi langkah
Langkah 1: Tentukan batas tanggung jawab
RFC 9110 mendefinisikan 421 sebagai penolakan dari origin karena URI target tampaknya telah salah diarahkan. Penyebabnya dapat berupa ketidakcocokan konfigurasi origin atau permintaan yang tidak sesuai dengan konteks koneksi saat ini. Aplikasi tidak boleh memetakan batas waktu upstream sembarangan, kesalahan DNS, atau sertifikat kedaluwarsa ke 421; kondisi-kondisi tersebut membutuhkan semantiknya masing-masing.
Langkah 2: Rekonstruksi konteks koneksi
Selama TLS handshake, SNI memilih sertifikat dan virtual host. Setelah enkripsi terbentuk, Host atau authority permintaan memilih target. HTTP/2 dapat membawa banyak permintaan dalam satu koneksi, tetapi penggunaan ulang hanya aman jika sertifikat, protokol, dan konfigurasi server mengizinkannya. Catat SNI, Host, skema, authority, ALPN, waktu mulai koneksi, dan backend yang dipilih, lalu bandingkan siapa pemilik koneksi dengan ke mana permintaan tersebut ditujukan.
TLS SNI: api-a.example
HTTP authority: api-b.example
ALPN: h2
selected virtual host: api-a.example
result: 421 from originLangkah 3: Tangani proxy, CDN, dan service mesh
Edge proxy harus mempertahankan authority asli, detail terminasi TLS, dan status koneksi upstream, sekaligus mencegah penggunaan ulang lintas-tenant pada koneksi upstream yang tidak kompatibel. Proxy boleh meneruskan 421 dari origin, tetapi tidak boleh menghasilkan 421 hanya karena rutenya sendiri gagal; gunakan kontrak 502, 503, atau kesalahan perutean milik proxy. Kunci pool pada service-mesh harus mencakup kolom yang memengaruhi pemilihan sertifikat dan virtual host, bukan hanya mem-pool berdasarkan IP dan port.
Langkah 4: Rancang percobaan ulang klien
Spesifikasi mengizinkan klien untuk mencoba ulang 421 pada koneksi yang berbeda, termasuk koneksi baru untuk origin target. Sebelum mencoba ulang, periksa idempotensi metode, kemampuan memutar ulang body permintaan, validitas token, dan apakah respons parsial atau efek samping telah terjadi. Untuk POST atau metode lain yang memiliki efek samping, gunakan kunci idempotensi atau konfirmasikan bahwa eksekusi belum terjadi sebelum mencoba ulang. Batasi percobaan dan catat alasannya; perulangan tetap tidak boleh menyembunyikan kesalahan konfigurasi.
Langkah 5: Observasi, perbaiki, dan uji regresi
Urai 421 berdasarkan SNI, authority, virtual host, versi protokol, dan node edge daripada hanya memantau jumlah global. Simpan ID koneksi yang telah disunting, keputusan rute, sidik jari sertifikat, respons origin, dan apakah klien membuka koneksi baru. Setelah perbaikan, uji tiga jalur: penggunaan ulang yang valid tidak boleh mengembalikan 421; koneksi yang tidak kompatibel harus secara konsisten mengembalikan 421; percobaan ulang pada koneksi baru harus mencapai respons akhir dari layanan target.
6. Contoh jawaban berkualitas tinggi
Saya akan memperlakukan 421 sebagai ketidakcocokan konteks koneksi atau authority origin, bukan sebagai pemadaman sementara yang umum. Pertama, korelasikan TLS SNI, HTTP authority, sertifikat, ALPN, connection pool, dan perutean virtual host untuk mengonfirmasi apakah permintaan menggunakan ulang koneksi yang tidak kompatibel. Origin boleh mengembalikan 421, sedangkan proxy harus meneruskannya alih-alih membuatnya sendiri. Klien dapat membuka koneksi baru untuk origin target dan mencoba ulang hanya setelah memeriksa idempotensi, pemutaran ulang body, dan kunci idempotensi. Ukur kode berdasarkan domain, protokol, node, dan pool, lalu buktikan perbaikannya dengan pengujian regresi untuk penggunaan ulang maupun koneksi baru.
7. Kesalahan umum
- Menulis ulang setiap 421 menjadi 503 → kehilangan bukti konteks koneksi → pertahankan 421 dan catat SNI serta authority di gateway.
- Memeriksa Host tetapi tidak memeriksa SNI → melewatkan penggunaan ulang sertifikat dan virtual host → catat target TLS maupun HTTP.
- Membiarkan proxy membuat 421 sendiri → melanggar batas tanggung jawab kode status → teruskan 421 origin dan gunakan kontrak 5xx yang jelas untuk kegagalan perutean proxy.
- Mencoba ulang POST tanpa syarat → dapat menduplikasi penulisan data → gunakan kunci idempotensi atau pastikan tidak ada eksekusi sebelum percobaan ulang yang dibatasi.
- Hanya menguji satu domain dan satu koneksi → melewatkan penggunaan ulang HTTP/2 → sertakan pengujian penggunaan ulang lintas-domain, penggunaan ulang yang tidak kompatibel, dan koneksi baru.
8. Pertanyaan lanjutan dan jawabannya
Apa perbedaan 421 dengan 503?
421 menunjukkan ketidakcocokan antara permintaan dan koneksi saat ini atau authority origin; koneksi baru khusus target dapat memulihkannya. 503 berarti layanan untuk sementara tidak dapat menangani permintaan, sering kali karena kapasitas, pemeliharaan, atau ketergantungan. Perbaikan, aturan percobaan ulang, dan dimensi peringatan (alert) keduanya berbeda.
Bisakah klien mencoba ulang 421 pada koneksi lama?
Klien tidak boleh terus menggunakan koneksi yang telah dinilai tidak cocok. Buka koneksi baru untuk origin target dan negosiasi ulang TLS serta protokol, dengan tetap memperhatikan backoff, pemutaran ulang body, dan status autentikasi.
Bolehkah proxy mengembalikan 421 ketika Host dan SNI berbeda?
Tidak boleh hanya berdasarkan inferensi proxy itu sendiri. Proxy harus mengikuti kontrak kesalahan peruteannya atau meneruskan permintaan agar diputuskan oleh origin. Jika proxy meneruskan 421 dari origin, pertahankan informasi sumber untuk diagnostik.
Bagaimana Anda membuktikan bahwa perbaikan pool tidak menurunkan performa?
Ukur secara terpisah penggunaan ulang yang valid, pool dengan kunci authority, dan penolakan penggunaan ulang yang tidak kompatibel. Bandingkan rasio 421, jumlah handshake, tail latency, jumlah koneksi, dan CPU. Tujuannya adalah menghilangkan penggunaan ulang yang salah sambil menjaga biaya handshake tambahan tetap sesuai anggaran.