Prom dan konteks
Sebuah get laluan API (API gateway) memerlukan klien menggunakan HTTP/3 tetapi menerima permintaan HTTP/1.1. Terangkan bila perlu mengembalikan 426, perkara yang perlu terkandung dalam respons, cara klien pulih, dan mengapa tidak setiap ketidakpadanan protokol perlu dijadikan 426.
HTTP 426 bermaksud pelayan enggan melaksanakan permintaan menggunakan protokol semasa tetapi mungkin berbuat demikian selepas klien menaik taraf. RFC 9110 memberikan contoh dengan Upgrade: HTTP/3.0. Ia merupakan permintaan naik taraf protokol yang boleh diambil tindakan, bukannya ralat parameter generik, kegagalan jabat tangan TLS, atau bukti bahawa pelayan tidak boleh menyediakan sumber itu langsung.
Perkara yang diuji oleh penemu duga
Penemu duga sedang menguji ketepatan semantik 426, sempadan antara medan Upgrade dan rundingan TLS atau versi HTTP, serta pengendalian anda terhadap cache, proksi, percubaan semula idempoten, telemetri dan keserasian klien. Anda juga perlu membezakan antara 400, 421, dan 505.
Soalan penjelasan
Sahkan sama ada peningkatan tersebut melibatkan HTTP, sambungan TLS, atau versi aplikasi; sama ada klien boleh mewujudkan protokol sasaran; sama ada kaedah tersebut selamat untuk dicuba semula; sama ada terdapat proksi di hadapan get laluan; dan sama ada permintaan asal mesti dihantar semula. Tanya sama ada sesetengah penyewa (tenants) mesti kekal pada protokol lama dan sama ada pelancaran kenari (canary) dan pengunduran (rollback) diperlukan.
Jawapan 30 saat
“Saya akan mengembalikan 426 hanya apabila protokol semasa menghalang pelayan daripada mengendalikan sumber, manakala protokol sasaran yang disokong boleh mengendalikannya. Respons harus menyertakan nilai Upgrade yang jelas dan penjelasan yang boleh dibaca manusia atau mesin. Klien mesti membuat sambungan sasaran sebelum memutuskan sama ada untuk mencuba semula; ia tidak boleh menganggap permintaan itu tidak dilaksanakan. Versi HTTP yang tidak disokong sepenuhnya ialah 505, ketidakpadanan penghalaan mungkin 421, dan ralat sintaks biasa ialah 400. Get laluan harus menjejak protokol, rantaian proksi, hasil peningkatan, tingkah laku cache dan amplifikasi percubaan semula.”
Jawapan mendalam
Langkah 1: Sahkan syarat pencetus
Syarat penting ialah “protokol semasa tidak sesuai, tetapi peningkatan mungkin berjaya.” Pelayan memerlukan protokol sasaran yang diketahui dan laluan peningkatan yang sebenar. Klien yang tidak diketahui, medan yang hilang dan versi aplikasi lama tidak layak secara automatik.
Langkah 2: Jadikan respons boleh diambil tindakan
Sertakan medan Upgrade yang menyenaraikan protokol yang diterima oleh pelayan, seperti HTTP/3.0, berserta badan ringkas atau kod ralat yang boleh dibaca mesin. Jangan hanya mengembalikan mesej samar-samar “sila naik taraf” atau mendedahkan topologi dalaman.
HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Content-Type: application/problem+json
{"type":"https://example.test/problems/upgrade-required","title":"Upgrade required"}Langkah 3: Asingkan peningkatan sambungan daripada percubaan semula aplikasi
Klien mula-mula mewujudkan sambungan protokol sasaran dan kemudian memutuskan sama ada untuk menghantar semula permintaan asal. Peningkatan sambungan ialah tindakan pengangkutan atau protokol, bukan perubahan pada medan aplikasi. Untuk POST bukan idempoten, klien memerlukan kunci keidempotenan (idempotency key), carian pelaksanaan dan kontrak percubaan semula khusus API.
Langkah 4: Kekalkan TLS pada lapisan yang betul
426 tidak menggantikan jabat tangan TLS atau ralat sijil. RFC 2817 membincangkan peningkatan HTTP/1.1 kepada TLS, tetapi penggunaan moden biasanya merundingkan TLS dan versi HTTP semasa mewujudkan sambungan. Jika permintaan tidak pernah mencapai peringkat di mana respons HTTP boleh dijana, rekodkan kegagalan jabat tangan dan bukannya mereka-reka 426.
Langkah 5: Gariskan sempadan kod status
400 bermaksud sintaks atau kandungan permintaan tidak sah; 421 bermaksud permintaan sampai ke pelayan yang tidak dapat menghasilkan respons untuk permintaan tersebut; 505 bermaksud pelayan tidak menyokong versi HTTP yang digunakan dalam permintaan. 426 menjanjikan kemungkinan penerusan selepas peningkatan, jadi ia tidak sepatutnya menyembunyikan protokol sasaran yang tidak tersedia atau sumber yang hilang.
Langkah 6: Reka bentuk tingkah laku proksi, cache dan percubaan semula
Proksi boleh menamatkan sambungan dan membuat permintaan lain, manakala klien boleh mencuba semula secara automatik. Nyatakan dasar Cache-Control yang disengajakan supaya cache kongsi tidak mengekalkan ralat migrasi selama-lamanya. Rekodkan protokol asal, hasil yang dirundingkan, rantaian proksi dan kiraan percubaan semula. Selaraskan belanjawan percubaan semula dengan had kadar (rate limits) dan pemutus litar (circuit breakers).
Langkah 7: Lindungi kenari dan pengunduran (rollback)
Gunakan pendekatan kenari untuk klien yang boleh menggunakan protokol sasaran, pantau kadar kejayaan, kependaman, jenis ralat dan penulisan pendua, kemudian kembangkan. Kekalkan protokol lama sehingga migrasi selesai dan sediakan pengunduran mengikut klien, penyewa atau rantau. Kiraan 426 sahaja bukan bukti kejayaan kerana perantara boleh menggunakan atau menulis semula respons.
Langkah 8: Sahkan pemulihan klien
Uji GET, PUT idempoten, POST bukan idempoten, sambungan jangka panjang, pemajuan proksi, capaian cache (cache hits), kegagalan TLS, nilai peningkatan yang tidak diketahui dan protokol sasaran yang tidak tersedia. Sahkan penyambungan semula, penulisan pendua, konteks pengesahan dan telemetri yang memisahkan 426, 421, 505 dan kegagalan jabat tangan.
Jawapan model
Saya mula-mula akan mengesahkan bahawa protokol semasa benar-benar menghalang pengendalian sumber, manakala protokol sasaran tersedia dan mempunyai laluan peningkatan yang jelas. Kemudian saya akan mengembalikan 426 dengan Upgrade: HTTP/3.0 dan ralat yang boleh dibaca mesin, tanpa membocorkan butiran dalaman. Klien mesti mewujudkan HTTP/3 dan menggunakan keidempotenan kaedah, kunci keidempotenan, dan carian pelaksanaan sebelum mencuba semula; ia tidak boleh membuat kesimpulan bahawa penulisan asal tidak berlaku. Kegagalan jabat tangan TLS tergolong dalam lapisan sambungan, versi HTTP yang langsung tidak disokong ialah 505, ketidakpadanan penghalaan mungkin 421, dan permintaan yang salah bentuk ialah 400. Saya akan melancarkan kenari mengikut keupayaan klien, memantau protokol, rantaian proksi, penulisan pendua dan kadar kejayaan, menetapkan sempadan cache dan percubaan semula, serta mengekalkan laluan pengunduran protokol lama. Ujian akan merangkumi kaedah, proksi, cache, sambungan panjang dan protokol sasaran yang tidak tersedia.
Kesilapan lazim
Menganggap 426 sebagai ralat generik klien lama
426 adalah mengenai peningkatan protokol yang mungkin membolehkan sumber yang sama disediakan. Versi aplikasi yang lama, medan yang hilang atau kebenaran yang dinafikan memerlukan kontrak aplikasinya yang tersendiri.
Menganggap medan Upgrade melakukan peningkatan secara automatik
Respons hanya memberitahu klien apa yang perlu dilakukan seterusnya; klien masih perlu membuat sambungan yang sesuai. Pelayan dan proksi mesti menyokong protokol sasaran, pengesahan, penghalaan, had dan telemetri.
Memainkan semula permintaan bukan idempoten secara automatik
426 boleh berlaku berhampiran sempadan pemprosesan permintaan. Tanpa kunci keidempotenan atau carian pelaksanaan, memainkan semula POST boleh menghasilkan kesan sampingan yang berulang.
Soalan susulan dan jawapan
Apakah perbezaan teras antara 426 dan 505?
426 menyatakan bahawa peningkatan mungkin menjadikan permintaan itu berjaya dan merujuk kepada protokol sasaran. 505 menyatakan bahawa pelayan tidak menyokong versi HTTP yang digunakan oleh permintaan dan biasanya tidak membuat janji peningkatan.
Jika proksi pinggir (edge proxy) menamatkan HTTP/3, bolehkah asal (origin) masih mengembalikan 426?
Pinggir harus mengendalikan rundingan dan penghalaan pada sempadannya dan menyerahkan konteks yang diperlukan kepada asal. Jika asal tidak dapat melihat protokol klien yang sebenar, ia tidak sepatutnya membuat kesimpulan daripada medan sambungan; sebaliknya rekodkan protokol proksi dan semantik pemajuan.
Bolehkah respons 426 dicache?
Hanya apabila kunci cache, keupayaan klien dan rancangan migrasi adalah jelas. Tetapan lalai harus mengelakkan cache kongsi daripada mengekalkan ralat migrasi protokol untuk tempoh yang lama, dengan medan respons menyatakan sebarang dasar jangka pendek.
Bagaimanakah POST boleh pulih dengan selamat daripada 426?
Gunakan kunci keidempotenan, carian status pelaksanaan dan belanjawan percubaan semula klien. Wujudkan sambungan sasaran terlebih dahulu, kemudian sahkan sama ada permintaan asal telah dilaksanakan. Jika ia tidak dapat disahkan, laporkan status belum selesai (pending) dan bukannya mencuba semula secara membuta tuli.
Bilakah sambungan perlu ditolak dan bukannya mengembalikan 426?
Jika TLS, ALPN, atau rundingan protokol peringkat lebih rendah gagal sebelum respons HTTP dapat dihasilkan, tutup sambungan dan rekodkan puncanya. 426 memerlukan respons HTTP yang boleh dihantar dan cadangan peningkatan yang boleh diambil tindakan.
Bagaimanakah anda membuktikan bahawa migrasi tidak membahayakan pengguna?
Gunakan pendekatan kenari mengikut keupayaan klien dan bandingkan kejayaan pasca-426, kependaman, penulisan pendua, kegagalan pengesahan, pengedaran proksi dan masa pengunduran. Metrik mesti mengasingkan percubaan semula pinggir, asal dan klien daripada hanya mengira respons 426 semata-mata.