Temu duga Backend: Bilakah API patut mengembalikan 421 Misdirected Request?

1. Gesaan dan konteks

Satu API multi-penyewa HTTPS menggunakan semula sambungan HTTP/2 merentasi beberapa domain. Sesetengah permintaan menerima 421 secara bersela, dan pasukan ingin menulis semulanya sebagai 503 dalam pengawal aplikasi. Nilai semantik 421, jelaskan SNI berbanding Host, dan reka pelan get laluan, asal (origin), klien, serta kebolehcerapan. Andaikan permintaan mungkin melalui CDN, proksi terbalik dan jaring perkhidmatan (service mesh).

2. Perkara yang diuji oleh penemu duga

Sama ada anda mengetahui bahawa 421 bermaksud permintaan telah sampai ke asal yang tidak mampu atau tidak bersedia untuk memberikan respons berwibawa bagi URI sasaran.
Sama ada anda boleh menghubungkan penggunaan semula sambungan, TLS SNI, Host permintaan, skema dan autoriti dalam satu rantaian diagnostik.
Sama ada anda memahami bahawa proksi tidak sepatutnya mereka cipta 421 daripada keputusan penghalaannya sendiri dan klien hanya perlu mencuba semula pada sambungan baharu.
Sama ada anda boleh memisahkan 421 daripada kegagalan huluan (upstream), 404, 503 dan ralat konfigurasi sijil dan bukannya sekadar menukar kod status.

3. Soalan penjelasan sebelum menjawab

Adakah 421 dijana oleh asal, get laluan, CDN atau aplikasi?
Adakah permintaan menggunakan HTTP/2 atau HTTP/3, dan bolehkah satu sambungan membawa pelbagai autoriti?
Apakah TLS SNI, HTTP Host dan hos maya yang dipilih pada lompatan (hop) terakhir?
Bolehkah klien membuka sambungan baharu untuk domain sasaran, dan adakah kaedah tersebut beridempoten atau sudah menghasilkan kesan sampingan?

4. Kerangka jawapan 30 saat

421 bermaksud asal percaya bahawa permintaan telah dihalakan ke sambungan atau hos maya yang salah, seperti gabungan sijil sambungan dan autoriti sasaran yang tidak serasi. Diagnosis SNI, Host, skema, autoriti, kumpulan sambungan (connection pooling) dan penghalaan asal sebelum menukar respons; jangan tulis semula sebagai 503. Asal boleh menghantar 421, manakala proksi harus memajukannya dan bukannya menjananya daripada keputusan penghalaannya sendiri. Klien boleh mencuba semula pada sambungan baharu, tertakluk kepada keidempotenan kaedah, kebolehulangan badan permintaan dan penangguhan (backoff). Hubung kaitkan ID sambungan, SNI, autoriti, laluan dan hasil percubaan semula dalam log.

5. Jawapan terperinci langkah demi langkah

Langkah 1: Tentukan sempadan tanggungjawab

RFC 9110 mentakrifkan 421 sebagai penolakan asal kerana URI sasaran kelihatan tersalah hala. Puncanya boleh jadi ketidakpadanan konfigurasi asal atau permintaan yang tidak sesuai dengan konteks sambungan semasa. Aplikasi tidak boleh memetakan tamat masa huluan sewenang-wenangnya, ralat DNS atau sijil tamat tempoh kepada 421; keadaan tersebut memerlukan semantik mereka sendiri.

Langkah 2: Bina semula konteks sambungan

Semasa jabat tangan TLS, SNI memilih sijil dan hos maya. Selepas penyulitan diwujudkan, Host atau autoriti permintaan memilih sasaran. HTTP/2 boleh membawa pelbagai permintaan pada satu sambungan, tetapi penggunaan semula hanya selamat apabila sijil, protokol dan konfigurasi pelayan membenarkannya. Rekodkan SNI, Host, skema, autoriti, ALPN, masa mula sambungan dan bahagian belakang (backend) yang dipilih, kemudian bandingkan siapa yang memiliki sambungan dengan ke mana permintaan itu pergi.

text

TLS SNI: api-a.example
HTTP authority: api-b.example
ALPN: h2
selected virtual host: api-a.example
result: 421 from origin

Langkah 3: Kendalikan proksi, CDN dan jaring perkhidmatan

Proksi pinggir harus mengekalkan autoriti asal, butiran penamatan TLS dan keadaan sambungan huluan, sambil menghalang penggunaan semula rentas penyewa pada sambungan huluan yang tidak serasi. Ia boleh memajukan 421 asal, tetapi ia tidak sepatutnya menjana 421 semata-mata kerana laluannya sendiri gagal; gunakan kontrak 502, 503 atau ralat penghalaan milik proksi. Kunci kolam jaring perkhidmatan mesti menyertakan medan yang mempengaruhi pemilihan sijil dan hos maya, dan bukannya mengumpulkan berdasarkan IP dan port semata-mata.

Langkah 4: Reka bentuk percubaan semula klien

Spesifikasi membenarkan klien mencuba semula 421 pada sambungan yang berbeza, termasuk sambungan baharu untuk asal sasaran. Sebelum mencuba semula, semak keidempotenan kaedah, kebolehulangan badan permintaan, kesahan token dan sama ada respons separa atau kesan sampingan telah berlaku. Untuk POST atau kaedah lain yang menghasilkan kesan sampingan, gunakan kunci keidempotenan atau sahkan bahawa pelaksanaan tidak berlaku sebelum mencuba semula. Hadkan percubaan dan rekodkan alasannya; gelung tetap tidak boleh menyembunyikan ralat konfigurasi.

Langkah 5: Perhati, betulkan dan lakukan ujian regresi

Pecahkan 421 mengikut SNI, autoriti, hos maya, versi protokol dan nod pinggir dan bukannya sekadar melihat kiraan global. Simpan ID sambungan yang disunting, keputusan laluan, cap jari sijil, respons asal dan sama ada klien membuka sambungan baharu. Selepas pembetulan, uji tiga laluan: penggunaan semula yang sah tidak boleh mengembalikan 421; sambungan yang tidak serasi harus secara konsisten mengembalikan 421; percubaan semula pada sambungan baharu harus mencapai respons akhir perkhidmatan sasaran.

6. Contoh jawapan berkualiti tinggi

Saya akan menganggap 421 sebagai ketidakpadanan konteks sambungan atau autoriti asal, bukan gangguan sementara yang generik. Pertama sekali, hubung kaitkan TLS SNI, autoriti HTTP, sijil, ALPN, kumpulan sambungan dan penghalaan hos maya untuk mengesahkan sama ada permintaan itu menggunakan semula sambungan yang tidak serasi. Asal boleh mengembalikan 421, manakala proksi harus memajukannya dan bukannya mereka ciptanya. Klien boleh membuka sambungan baharu untuk asal sasaran dan mencuba semula hanya selepas memeriksa keidempotenan, kebolehulangan badan dan kunci keidempotenan. Ukur kod mengikut domain, protokol, nod dan kumpulan, kemudian buktikan pembetulan dengan kedua-dua ujian regresi penggunaan semula dan sambungan baharu.

7. Kesilapan lazim

Menulis semula setiap 421 sebagai 503 → kehilangan bukti konteks sambungan → kekalkan 421 dan log SNI serta autoriti di get laluan.
Menyemak Host tetapi bukan SNI → terlepas penggunaan semula sijil dan hos maya → rekodkan kedua-dua sasaran TLS dan HTTP.
Membiarkan proksi mereka cipta 421 → melanggar sempadan tanggungjawab kod status → majukan 421 asal dan gunakan kontrak 5xx yang jelas untuk kegagalan penghalaan proksi.
Mencuba semula POST tanpa syarat → boleh menduplikasi penulisan → gunakan kunci keidempotenan atau sahkan tiada pelaksanaan sebelum percubaan semula yang dihadkan.
Hanya menguji satu domain dan satu sambungan → terlepas penggunaan semula HTTP/2 → sertakan ujian penggunaan semula rentas domain, penggunaan semula tidak serasi dan sambungan baharu.

8. Soalan susulan dan jawapan

Bagaimanakah 421 berbeza daripada 503?

421 menunjukkan ketidakpadanan antara permintaan dengan sambungan semasa atau autoriti asal; sambungan baharu khusus sasaran boleh memulihkannya. 503 bermakna perkhidmatan tidak dapat mengendalikan permintaan buat sementara waktu, selalunya disebabkan oleh kapasiti, penyelenggaraan atau kebergantungan. Pembetulan, peraturan percubaan semula dan dimensi amaran mereka adalah berbeza.

Bolehkah klien mencuba semula 421 pada sambungan lama?

Ia tidak sepatutnya terus menggunakan sambungan yang telah dinilai tidak sesuai. Buka sambungan baharu untuk asal sasaran dan runding semula TLS serta protokol, sambil menghormati penangguhan, kebolehulangan badan dan status pengesahan.

Bolehkah proksi mengembalikan 421 apabila Host dan SNI berbeza?

Bukan semata-mata daripada inferens proksi itu sendiri. Ia harus mematuhi kontrak ralat penghalaannya atau memajukan permintaan untuk diputuskan oleh asal. Jika ia memajukan 421 asal, kekalkan maklumat sumber untuk diagnosis.

Bagaimanakah anda membuktikan pembaikan kolam tidak menjejaskan prestasi?

Ukur penggunaan semula yang sah, kolam berkunci autoriti dan penggunaan semula tidak serasi yang ditolak secara berasingan. Bandingkan kadar 421, kiraan jabat tangan, pendaman ekor (tail latency), kiraan sambungan dan CPU. Matlamatnya adalah untuk menghapuskan penggunaan semula yang salah sambil mengekalkan kos jabat tangan tambahan dalam lingkungan bajet.