Wawancara umum: Bagaimana cara Anda mendiagnosis HTTP 431 Request Header Fields Too Large?

1. Pertanyaan dan konteks

Setelah login, sebuah halaman mengakses API melalui CDN, load balancer, dan service mesh. Beberapa pengguna menerima 431 Request Header Fields Too Large; jendela penyamaran (incognito) dan curl berhasil. Jelaskan semantik status, diagnosis hop-demi-hop, remediasi, dan validasi rilis. Asumsikan HTTP/1.1 atau HTTP/2 dapat digunakan dan log tidak boleh berisi cookie lengkap atau nilai otorisasi.

2. Apa yang dievaluasi oleh pewawancara

• Membedakan blok header agregat yang terlalu besar dari satu bidang yang terlalu besar dan mengetahui bahwa 431 adalah respons kesalahan klien sebelum pemrosesan permintaan.
• Mengukur melalui CDN, gateway, proxy, dan aplikasi alih-alih hanya mengubah server aplikasi.
• Mengenali pertumbuhan cookie, duplikasi nilai Set-Cookie, token yang panjang, dan header penerusan sebagai penyebab yang mungkin.
• Mengurangi status klien, merotasi kredensial, dan menambahkan observabilitas ukuran tanpa melemahkan keamanan.

3. Pertanyaan untuk diklarifikasi terlebih dahulu

1. Hop mana yang menghasilkan 431, dan apakah header respons, identitas server, atau log edge dapat mengidentifikasinya?
2. Berapa total byte header dari permintaan yang gagal, bidang terbesar, dan protokolnya?
3. Apakah browser mengirimkan cookie lama, cookie lintas subdomain, atau data sesi yang terus bertambah?
4. Apakah setiap lapisan membatasi header agregat, suatu bidang, baris permintaan, atau buffer, dan apakah ada batas decoding HTTP/2?

4. Jawaban 30 detik

431 berarti server menolak permintaan karena header permintaan agregat atau suatu bidang melebihi batas yang diizinkan; RFC 6585 tidak mendefinisikan satu batas byte universal. Ukur total yang telah diredaksi dan bidang terbesar dari klien melalui edge, gateway, proxy, dan aplikasi, lalu temukan hop pertama yang mengembalikan 431. Ketika hanya browser yang gagal, periksa cookie, duplikat Set-Cookie, dan otorisasi sebelum menaikkan batas. Hapus status klien, perpendek atau ganti token dengan referensi sesi sisi server, buat kedaluwarsa cookie lama, dan selaraskan anggaran di seluruh hop. Naikkan batas hanya setelah analisis kapasitas dan denial-of-service.

5. Jawaban langkah demi langkah

Langkah 1: Konfirmasi status dan hop yang memancarkan

Catat node yang dilalui, protokol, header respons, dan ID korelasi. Putar ulang permintaan minimal langsung ke origin, melewati CDN, melalui gateway, dan dengan header browser yang diredaksi; bandingkan di mana 431 pertama kali muncul. Beberapa proxy menggunakan 400 atau kode vendor seperti 494 untuk batas yang serupa, jadi gabungkan status dengan log node dan konfigurasi.

Langkah 2: Ukur header dalam byte

Hitung panjang byte yang dikodekan untuk setiap bidang dan catat total header permintaan, baris permintaan, bidang terbesar, dan jumlah bidang. Jumlah karakter bukanlah jumlah byte, dan blok header HTTP/2 yang dikompresi bukanlah total bidang yang didekodekan. Simpan hanya nama bidang, panjang, awalan hash, dan ID permintaan di log; jangan pernah mencatat nilai cookie, token bearer, atau Referer lengkap.

Langkah 3: Temukan sumber khusus browser

Cookie adalah tersangka utama: cookie dengan nama yang sama pada beberapa path atau subdomain, data pengguna yang disimpan dalam cookie, dan nilai baru yang ditambahkan pada setiap respons membuat permintaan berikutnya membengkak. Periksa Domain, Path, kedaluwarsa, dan perilaku penghapusan Set-Cookie; verifikasi bahwa nama lama benar-benar kedaluwarsa dan tidak hanya ditimpa pada satu path. Buat token otorisasi tetap pendek dan letakkan data yang dapat berubah dalam sesi sisi server yang terkontrol atau penyimpanan yang aman.

Langkah 4: Perhitungkan hop proxy dan HTTP/2

Setiap hop mungkin memiliki batas agregat, per bidang, dan buffer yang berbeda, sementara penerusan menambahkan X-Forwarded-*, pelacakan, dan bidang autentikasi. Publikasikan anggaran sebagai kontrak konfigurasi dan gunakan batas terkecil sebagai batas atas desain klien. HTTP/2 menggunakan HPACK untuk kompresi transport, tetapi endpoint tetap mendekode bidang dan menerapkan batas; rasio kompresi tidak membuktikan header bisnis aman. Berikan peringatan tentang penolakan gateway ketika aplikasi tidak menerima apa pun.

Langkah 5: Pilih remediasi dan pertahanan

Hapus cookie duplikat, kurangi konten sesi, pindahkan status ke sisi server, dan kirimkan hanya referensi pendek yang tidak dapat ditebak. Tetapkan kebijakan panjang token, rotasi, dan pencabutan; tolak bidang kustom yang tidak dikenal atau luar biasa besar. Naikkan batas hanya setelah memeriksa memori penguraian (parsing), konkurensi, dan biaya denial-of-service, dengan anggaran per-penyewa (per-tenant) atau per-rute yang masuk akal.

6. Contoh jawaban model

Saya akan mengidentifikasi hop pertama yang mengembalikan 431 dan mengukur permintaan yang gagal setelah redaksi: total byte header, bidang terbesar, baris permintaan, jumlah bidang, dan versi HTTP. Kegagalan khusus browser mengarah pertama kali pada cookie duplikat atau lintas-subdomain, pertumbuhan data sesi, atau panjang otorisasi; mengubah batas origin saja tidak aman karena CDN, load balancer, atau mesh mungkin menolaknya lebih awal. Saya akan membuat cookie lama kedaluwarsa, meminimalkan status klien, menggunakan referensi sesi sisi server, dan menyelaraskan anggaran hop. Kompresi transport HTTP/2 tidak menghilangkan batas yang didekodekan. Telemetri produksi akan mengumpulkan persentil ukuran berdasarkan hop dan nama bidang sambil menyimpan panjang dan awalan hash, tidak pernah kredensial.

7. Kesalahan umum

• Hanya menghapus cookie browser: Ini mungkin bersifat sementara; lacak pembuat (setter), Domain, Path, dan logika kedaluwarsa untuk menghapus akar penyebab Set-Cookie duplikat.
• Mengasumsikan 431 selalu berarti 8 KB: RFC 6585 tidak menetapkan batas universal; periksa setiap lapisan dan ukur byte.
• Hanya menaikkan batas origin: Edge atau gateway masih dapat menolaknya terlebih dahulu, dan biaya penguraian meningkat; selaraskan anggaran dan nilai kapasitas.
• Mencatat header permintaan lengkap: Ini mengekspos cookie dan token; pertahankan nama, panjang, awalan hash, dan ID korelasi.
• Mengasumsikan kompresi HTTP/2 menghilangkan batas: Endpoint mendekode bidang dan menerapkan batas; uji kompresi transport secara terpisah dari ukuran yang didekodekan.

8. Pertanyaan lanjutan dan tanggapan

Pertanyaan lanjutan 1: Mengapa curl berfungsi sementara browser gagal?

Browser secara otomatis mengirimkan setiap cookie, autentikasi, dan header pelacakan yang cocok dengan domain; curl biasanya berukuran lebih kecil. Ekspor permintaan browser, hapus bidang dengan pencarian biner, dan ukur setiap hop untuk memisahkan konten klien dari batas proxy.

Pertanyaan lanjutan 2: Bisakah JWT disimpan dalam cookie?

Bisa, tetapi setiap permintaan menanggung biaya byte token tersebut dan beberapa cookie dapat melebihi batas. Simpan referensi pendek atau klaim minimal di sisi klien, simpan data yang dapat berubah dan pencabutan di sisi server, serta terapkan anggaran panjang dan rotasi.

Pertanyaan lanjutan 3: Kapan menaikkan batas dapat diterima?

Hanya jika persyaratannya nyata, setiap hop dapat menyerap memori penguraian dan konkurensi, serta uji kapasitas, batas waktu (timeout), dan denial-of-service terpenuhi. Pertahankan telemetri ukuran, batas kecepatan (rate limit), dan konfigurasi rollback; batas atas yang lebih tinggi bukanlah satu-satunya perbaikan.