Perintah dan konteks
Klien yang menggunakan penggunaan ulang koneksi HTTP/2 secara berkala menerima 421 Misdirected Request saat memanggil beberapa domain HTTPS. Jelaskan arti dari respons tersebut, cara membedakan perutean protokol dari kesalahan aplikasi, cara memeriksa SNI, authority, dan rantai proksi, serta cara melakukan retry dengan aman.
Hal yang dievaluasi oleh pewawancara
- Pemahaman tentang 421 sebagai kondisi di mana server tidak dapat melayani scheme dan authority yang diminta pada jalur saat ini.
- Menghubungkan TLS SNI, sertifikat, penggunaan ulang koneksi HTTP/2, dan perutean reverse-proxy.
- Menelusuri permintaan di seluruh klien, edge, proksi, dan origin.
- Melakukan retry pada koneksi baru tanpa menduplikasi efek samping.
Pertanyaan untuk diklarifikasi sebelum menjawab
- Apakah 421 terjadi pada HTTP/1.1, HTTP/2, atau HTTP/3, dan hanya pada koneksi yang digunakan ulang?
- Apakah scheme, authority, Host, SNI, dan SAN sertifikat sesuai?
- Apakah DNS, load balancer, CDN, atau service mesh mengirimkan beberapa domain ke satu koneksi?
- Apakah proksi menulis ulang Host, authority, atau detail terminasi TLS?
- Apakah permintaan bersifat idempoten, dilindungi oleh kunci idempotensi, dan masih dalam batas waktu retry?
Kerangka jawaban 30 detik
421 berarti server menganggap permintaan dikirim ke koneksi atau node yang salah, bukan karena validasi bisnis normal gagal. Saya mencatat authority, SNI, sertifikat, ID koneksi, dan lompatan proksi, lalu membandingkan jalur yang berhasil dan yang gagal. Jika ketidakcocokan reuse atau perutean terkonfirmasi, klien dapat mencoba ulang pada koneksi baru, secara otomatis hanya untuk permintaan idempoten atau yang memiliki kunci idempotensi dan dengan batas maksimum. Perbaikannya biasanya berupa pengelompokan connection pool, preservasi SNI/Host, atau perutean proksi, bukan sekadar menambah retry secara membabi buta.
Analisis mendalam langkah demi langkah
Langkah 1: Tentukan batasan 421
RFC 9110 mendefinisikan 421 ketika origin menganggap permintaan salah diarahkan dan tidak dapat menghasilkan respons untuk kombinasi scheme dan authority pada URI tersebut. Ini berbeda dari sumber daya yang hilang, izin ditolak, atau kesalahan validasi bisnis.
Langkah 2: Verifikasi identitas target
Ambil URL scheme, authority, Host, SNI, SAN sertifikat, ALPN, dan penanda penggunaan ulang koneksi. Permintaan HTTPS memerlukan sertifikat dan identitas TLS yang mencakup origin target; resolusi DNS saja tidak cukup.
Langkah 3: Periksa pooling dan reuse
HTTP/2 dapat membawa banyak permintaan dalam satu koneksi, tetapi server dapat menolak authority pada koneksi yang sudah terbentuk. Periksa apakah pool dikelompokkan berdasarkan proksi, parameter TLS, dan authority, serta apakah koneksi lama digunakan ulang secara tidak tepat.
Langkah 4: Telusuri rantai proksi
Catat ID permintaan, authority, SNI, upstream yang dipilih, dan status di CDN, gateway, service mesh, dan origin. Bandingkan node yang dilewati oleh permintaan yang berhasil dan permintaan 421 untuk menemukan penulisan ulang Host, SNI yang hilang, atau perutean yang buruk.
Langkah 5: Coba ulang pada koneksi baru
Spesifikasi mengizinkan klien untuk mencoba ulang 421 pada koneksi yang berbeda. Koneksi baru harus mengulang binding DNS, TLS, ALPN, dan authority; mengirimkan permintaan yang sama pada koneksi lama tidaklah cukup. Periksa idempotensi metode, body yang dapat diputar ulang, dan batas waktu terlebih dahulu.
Langkah 6: Perbaiki perutean di sisi server
Jaga agar konfigurasi scheme, authority, SNI, dan sertifikat tetap selaras di edge dan origin, serta pertahankan field yang diperlukan saat meneruskan permintaan. Untuk wildcard atau sertifikat bersama, tentukan secara eksplisit domain mana yang boleh berbagi koneksi dan domain mana yang harus diisolasi.
Langkah 7: Tambahkan observabilitas dan uji regresi
Ukur 421 berdasarkan authority, ID koneksi, protokol, node, dan versi sertifikat. Gunakan uji beban HTTP/2 multi-domain, tombol pengalih reuse, dan fault injection untuk memvalidasi perbaikan serta memastikan retry koneksi baru tidak menyembunyikan kecacatan perutean yang persisten.
Contoh jawaban berkualitas tinggi
Pertama, saya akan memeriksa apakah 421 hanya muncul pada koneksi HTTP/2 yang digunakan ulang. Log mencatat scheme, authority, Host, SNI, SAN sertifikat, ALPN, ID koneksi, dan upstream proksi. Jika permintaan yang gagal ke api.example.com digunakan ulang pada koneksi yang hanya dikonfigurasi untuk static.example.com, itu cocok dengan 421. Klien mencoba ulang satu kali pada koneksi baru hanya untuk GET atau permintaan dengan kunci idempotensi; operasi penulisan diteruskan ke lapisan bisnis untuk konfirmasi. Server memeriksa apakah CDN, gateway, dan origin mempertahankan authority dan SNI serta mengelompokkan pool berdasarkan domain. Kemudian saya mengukur 421 berdasarkan domain dan node serta memvalidasi perbaikan dengan uji penggunaan ulang multi-domain.
Kesalahan umum
- Memperlakukan 421 sebagai 404, 401, atau 400 biasa dan mengubah parameter bisnis.
- Memeriksa DNS tetapi tidak memeriksa SNI, SAN sertifikat, authority, atau penerusan proksi.
- Melakukan retry terus-menerus pada koneksi yang sama setelah 421.
- Memutar ulang POST yang memiliki efek samping secara otomatis tanpa perlindungan idempotensi.
- Hanya menyimpan kesalahan akhir klien dan kehilangan bukti koneksi serta perutean per lompatan.
Pertanyaan lanjutan dan tanggapan
Pertanyaan lanjutan 1: Apa perbedaan utama antara 421 dan 400?
400 biasanya mengindikasikan sintaks permintaan yang tidak valid atau masalah message framing. 421 menunjukkan ketidakcocokan antara target dan server atau koneksi saat ini, terutama perutean, authority, atau identitas TLS.
Pertanyaan lanjutan 2: Mengapa HTTP/2 lebih sering memunculkan hal ini?
HTTP/2 mendukung multipleksing dan koneksi bersama, sehingga klien dapat mengirimkan beberapa authority melalui satu koneksi TLS. Server yang menolak kombinasi tersebut akan mengembalikan 421.
Pertanyaan lanjutan 3: Apakah mengubah IP akan memperbaikinya?
Belum tentu. Jika pooling, SNI, atau penulisan ulang proksi salah, IP yang berbeda hanya mengubah probabilitas. Verifikasi identitas TLS koneksi baru dan rute lengkapnya terlebih dahulu.
Pertanyaan lanjutan 4: Kapan POST boleh dicoba ulang?
Hanya jika API memiliki kunci idempotensi, deduplikasi server, atau kontrak replay yang eksplisit, dan body tetap tersedia dalam batas waktu.
Pertanyaan lanjutan 5: Bagaimana Anda membuktikan bahwa penggunaan ulang koneksi adalah penyebabnya?
Bandingkan kondisi saat reuse diaktifkan dan dinonaktifkan, ID koneksi, urutan authority, dan node yang gagal. Koneksi baru yang berhasil ditambah kegagalan reuse yang dapat direproduksi memberikan bukti yang lebih kuat.
Pertanyaan lanjutan 6: Apa yang harus dipantau untuk peringatan (alert) produksi?
Pantau tingkat 421, keberhasilan retry, dan pembuatan koneksi baru berdasarkan authority, protokol, edge node, dan versi sertifikat. Lonjakan sering kali menandakan adanya pergeseran pada perutean atau sertifikat.