Prompt dan konteks
Sebuah API gateway mewajibkan klien untuk menggunakan HTTP/3 tetapi menerima permintaan HTTP/1.1. Jelaskan kapan harus mengembalikan 426, apa isi respons tersebut, bagaimana klien melakukan pemulihan, dan mengapa tidak setiap ketidakcocokan protokol harus menjadi 426.
HTTP 426 berarti server menolak untuk menjalankan permintaan menggunakan protokol saat ini, tetapi mungkin dapat melakukannya setelah klien melakukan upgrade. RFC 9110 memberikan contoh dengan Upgrade: HTTP/3.0. Ini adalah permintaan upgrade protokol yang dapat ditindaklanjuti (actionable), bukan kesalahan parameter umum, kegagalan TLS handshake, atau bukti bahwa server sama sekali tidak dapat melayani resource tersebut.
Hal yang diuji oleh pewawancara
Pewawancara sedang menguji pemahaman semantik 426 yang tepat, batasan antara field Upgrade dan negosiasi TLS atau versi HTTP, serta penanganan Anda terhadap cache, proxy, percobaan ulang idempoten, telemetri, dan kompatibilitas klien. Anda juga harus membedakan antara 400, 421, dan 505.
Pertanyaan klarifikasi
Konfirmasikan apakah upgrade ini terkait dengan HTTP, koneksi TLS, atau versi aplikasi; apakah klien dapat membentuk protokol target; apakah metode tersebut aman untuk dicoba ulang; apakah ada proxy di depan gateway; dan apakah permintaan awal harus dikirim ulang. Tanyakan apakah beberapa tenant harus tetap menggunakan protokol lama dan apakah rilis canary serta rollback diperlukan.
Jawaban 30 detik
“Saya akan mengembalikan 426 hanya ketika protokol saat ini menghalangi server untuk menangani resource, sementara protokol target yang didukung dapat menanganinya. Respons harus menyertakan nilai Upgrade yang eksplisit dan penjelasan yang dapat dibaca manusia atau mesin. Klien harus membuat koneksi target sebelum memutuskan apakah akan mencoba ulang; klien tidak boleh berasumsi bahwa permintaan tersebut belum dieksekusi. Versi HTTP yang sepenuhnya tidak didukung adalah 505, ketidakcocokan routing bisa berupa 421, dan kesalahan sintaksis biasa adalah 400. Gateway harus melacak protokol, rantai proxy, hasil upgrade, perilaku cache, dan amplifikasi percobaan ulang.”
Jawaban mendalam
Langkah 1: Konfirmasikan kondisi pemicu
Kondisi esensialnya adalah “protokol saat ini tidak sesuai, tetapi upgrade mungkin berhasil.” Server membutuhkan protokol target yang diketahui dan jalur upgrade yang nyata. Klien yang tidak dikenal, field yang hilang, dan versi aplikasi lama tidak serta-merta memenuhi syarat.
Langkah 2: Buat respons dapat ditindaklanjuti (actionable)
Sertakan field Upgrade yang mencantumkan protokol yang diterima server, seperti HTTP/3.0, ditambah body singkat atau kode kesalahan yang dapat dibaca mesin. Jangan hanya mengembalikan pesan ambigu “harap upgrade” atau mengekspos topologi internal.
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: Pisahkan upgrade koneksi dari percobaan ulang aplikasi
Klien pertama-tama membuat koneksi protokol target dan kemudian memutuskan apakah akan mengirim ulang permintaan asli. Upgrade koneksi adalah tindakan transport atau protokol, bukan perubahan pada field aplikasi. Untuk POST non-idempoten, klien memerlukan kunci idempotensi (idempotency key), pengecekan status eksekusi, dan kontrak percobaan ulang khusus API.
Langkah 4: Jaga TLS pada lapisan yang tepat
426 tidak menggantikan kesalahan sertifikat atau TLS handshake. RFC 2817 membahas upgrade HTTP/1.1 ke TLS, tetapi penerapan modern biasanya menegosiasikan versi TLS dan HTTP saat membuat koneksi. Jika permintaan tidak pernah mencapai tahap di mana respons HTTP dapat dibuat, catat sebagai kegagalan handshake alih-alih merekayasa status 426.
Langkah 5: Tentukan batasan status code
400 berarti sintaksis atau konten permintaan tidak valid; 421 berarti permintaan mencapai server yang tidak dapat menghasilkan respons untuk permintaan tersebut; 505 berarti server tidak mendukung versi HTTP yang digunakan dalam permintaan. 426 menjanjikan kemungkinan kelanjutan setelah upgrade, sehingga tidak boleh menyembunyikan protokol target yang tidak tersedia atau resource yang hilang.
Langkah 6: Rancang perilaku proxy, cache, dan percobaan ulang
Proxy dapat mengakhiri koneksi dan membuat permintaan lain, sementara klien dapat mencoba ulang secara otomatis. Nyatakan kebijakan Cache-Control yang terencana agar shared cache tidak menyimpan kesalahan migrasi tanpa batas waktu. Catat protokol asli, hasil yang dinegosiasikan, rantai proxy, dan jumlah percobaan ulang. Selaraskan batas percobaan ulang (retry budget) dengan rate limit dan circuit breaker.
Langkah 7: Amankan rilis canary dan rollback
Lakukan rilis canary pada klien yang dapat menggunakan protokol target, amati tingkat keberhasilan, latensi, jenis kesalahan, dan penulisan duplikat, lalu perluas. Pertahankan protokol lama hingga migrasi selesai dan siapkan rollback berdasarkan klien, tenant, atau wilayah. Jumlah 426 saja bukan bukti keberhasilan karena perantara dapat mengonsumsi atau menulis ulang respons.
Langkah 8: Verifikasi pemulihan klien
Uji GET, PUT idempoten, POST non-idempoten, koneksi persisten (long-lived), penerusan proxy, cache hit, kegagalan TLS, nilai upgrade yang tidak dikenal, dan protokol target yang tidak tersedia. Verifikasi rekoneksi, penulisan duplikat, konteks autentikasi, dan telemetri yang memisahkan 426, 421, 505, serta kegagalan handshake.
Jawaban model
Pertama, saya akan memverifikasi bahwa protokol saat ini benar-benar menghalangi penanganan resource, sementara protokol target tersedia dan memiliki jalur upgrade yang jelas. Kemudian saya akan mengembalikan 426 dengan Upgrade: HTTP/3.0 dan kesalahan yang dapat dibaca mesin, tanpa membocorkan detail internal. Klien harus membentuk HTTP/3 dan menggunakan idempotensi metode, kunci idempotensi, serta pengecekan eksekusi sebelum mencoba ulang; klien tidak dapat menyimpulkan bahwa penulisan asli tidak terjadi. Kegagalan TLS handshake berada pada lapisan koneksi, versi HTTP yang sama sekali tidak didukung adalah 505, ketidakcocokan routing bisa berupa 421, dan permintaan yang salah format adalah 400. Saya akan menerapkan rilis canary berdasarkan kemampuan klien, memantau protokol, rantai proxy, penulisan duplikat, dan tingkat keberhasilan, menetapkan batasan cache dan percobaan ulang, serta mempertahankan jalur rollback ke protokol lama. Pengujian akan mencakup berbagai metode, proxy, cache, koneksi panjang, dan protokol target yang tidak tersedia.
Kesalahan umum
Memperlakukan 426 sebagai kesalahan umum klien lama
426 berkaitan dengan upgrade protokol yang memungkinkan resource yang sama untuk dilayani. Versi aplikasi yang lama, field yang hilang, atau izin yang ditolak memerlukan kontrak aplikasinya masing-masing.
Mengasumsikan field Upgrade melakukan upgrade secara otomatis
Respons hanya memberi tahu klien apa yang harus dilakukan selanjutnya; klien tetap harus membuat koneksi yang sesuai. Server dan proxy harus mendukung protokol target, autentikasi, routing, batasan, dan telemetri.
Memutar ulang permintaan non-idempoten secara otomatis
426 dapat terjadi di dekat batas pemrosesan permintaan. Tanpa kunci idempotensi atau pengecekan eksekusi, memutar ulang permintaan POST dapat menimbulkan efek samping duplikat.
Pertanyaan lanjutan dan jawaban
Apa perbedaan mendasar antara 426 dan 505?
426 menyatakan bahwa sebuah upgrade dapat membuat permintaan berhasil dan mengarahkan ke protokol target. 505 menyatakan bahwa server tidak mendukung versi HTTP yang digunakan oleh permintaan dan biasanya tidak memberikan jaminan upgrade.
Jika edge proxy mengakhiri HTTP/3, bisakah origin tetap mengembalikan 426?
Edge harus menangani negosiasi dan routing pada batasannya serta meneruskan konteks yang diperlukan ke origin. Jika origin tidak dapat melihat protokol klien yang sebenarnya, origin tidak boleh menyimpulkannya dari field koneksi; sebaliknya, catat protokol proxy dan semantik penerusan.
Bisakah respons 426 disimpan di cache?
Hanya jika cache key, kemampuan klien, dan rencana migrasi didefinisikan secara eksplisit. Standarnya adalah menghindari shared cache menyimpan kesalahan migrasi protokol dalam jangka waktu lama, dengan field respons yang menyatakan kebijakan berdurasi singkat jika diperlukan.
Bagaimana sebuah permintaan POST dapat pulih secara aman dari 426?
Gunakan kunci idempotensi, pengecekan status eksekusi, dan anggaran percobaan ulang (retry budget) klien. Buat koneksi target terlebih dahulu, lalu konfirmasikan apakah permintaan awal telah dieksekusi. Jika tidak dapat dikonfirmasi, laporkan status tertunda (pending) daripada mencoba ulang secara membabi buta.
Kapan koneksi harus ditolak alih-alih mengembalikan 426?
Jika negosiasi TLS, ALPN, atau protokol tingkat bawah gagal sebelum respons HTTP dapat dibuat, tutup koneksi dan catat alasannya. 426 memerlukan respons HTTP yang dapat dikirim dan saran upgrade yang dapat ditindaklanjuti.
Bagaimana Anda membuktikan bahwa migrasi tidak merugikan pengguna?
Gunakan rilis canary berdasarkan kemampuan klien dan bandingkan keberhasilan pasca-426, latensi, penulisan duplikat, kegagalan autentikasi, distribusi proxy, dan waktu rollback. Metrik harus memisahkan percobaan ulang pada edge, origin, dan klien, bukan hanya menghitung jumlah respons 426.