Temuduga umum: Bagaimanakah anda mendiagnosis HTTP 431 Request Header Fields Too Large?

1. Soalan dan konteks

Selepas log masuk, satu halaman mencapai API melalui CDN, pengimbang beban dan jaring perkhidmatan (service mesh). Sesetengah pengguna menerima 431 Request Header Fields Too Large; tetingkap inkognito dan curl berfungsi. Terangkan semantik status, diagnosis lompatan demi lompatan (hop-by-hop), pemulihan dan pengesahan pelepasan. Andaikan HTTP/1.1 atau HTTP/2 mungkin digunakan dan log tidak boleh mengandungi kuki penuh atau nilai pengesahan.

2. Perkara yang dinilai oleh penemu duga

• Membezakan blok pengepala agregat yang bersaiz terlalu besar daripada satu medan yang bersaiz terlalu besar dan mengetahui bahawa 431 ialah respons ralat klien sebelum pemprosesan permintaan.
• Mengukur melalui CDN, get laluan, proksi dan aplikasi dan bukannya hanya menukar pelayan aplikasi.
• Mengenal pasti pertambahan saiz kuki, nilai Set-Cookie pendua, token yang panjang dan pengepala pemajuan sebagai punca yang mungkin.
• Mengurangkan keadaan klien, memutarkan kelayakan dan menambah kebolehmerhatian saiz tanpa melemahkan keselamatan.

3. Soalan untuk dijelaskan terlebih dahulu

1. Lompatan mana yang menjana 431, dan adakah pengepala respons, identiti pelayan atau log pinggir boleh mengenal pastinya?
2. Apakah jumlah bait pengepala permintaan yang gagal, medan terbesar dan protokolnya?
3. Adakah pelayar menghantar kuki lama, kuki merentas subdomain atau data sesi yang semakin bertambah?
4. Adakah setiap lapisan mengehadkan pengepala agregat, satu medan, baris permintaan atau penimbal, dan adakah had penyahkodan HTTP/2 wujud?

4. Jawapan 30 saat

431 bermaksud pelayan menolak permintaan kerana pengepala permintaan agregat atau satu medan melebihi had yang dibenarkan; RFC 6585 tidak mentakrifkan satu had bait sejagat. Ukur jumlah yang disunting dan medan terbesar daripada klien melalui pinggir, get laluan, proksi dan aplikasi, kemudian cari lompatan pertama yang mengembalikan 431. Apabila hanya pelayar yang gagal, periksa kuki, pendua Set-Cookie dan kebenaran sebelum meningkatkan had. Buang keadaan klien, pendekkan atau gantikan token dengan rujukan sesi bahagian pelayan, tamatkan tempoh kuki lama dan selaraskan bajet merentasi lompatan. Tingkatkan had hanya selepas analisis kapasiti dan penafian perkhidmatan (denial-of-service).

5. Jawapan langkah demi langkah

Langkah 1: Sahkan status dan lompatan yang memancarkan

Rekod nod yang dilalui, protokol, pengepala respons dan ID korelasi. Mainkan semula permintaan minimum terus ke asal, memintas CDN, melalui get laluan dan dengan pengepala pelayar yang disunting; bandingkan di mana 431 mula-mula muncul. Sesetengah proksi menggunakan 400 atau kod vendor seperti 494 untuk had yang serupa, jadi gabungkan status dengan log nod dan konfigurasi.

Langkah 2: Ukur pengepala dalam bait

Kira panjang bait yang dikodkan untuk setiap medan dan rekod jumlah pengepala permintaan, baris permintaan, medan terbesar dan bilangan medan. Kiraan aksara bukan kiraan bait, dan blok pengepala HTTP/2 yang dimampatkan bukan jumlah medan yang dinyahkod. Simpan hanya nama medan, panjang, awalan cincangan (hash) dan ID permintaan dalam log; jangan sekali-kali merekodkan nilai kuki, token pembawa atau Referer yang lengkap.

Langkah 3: Cari punca khusus pelayar

Kuki adalah suspek utama: kuki dengan nama yang sama pada beberapa laluan atau subdomain, data pengguna yang disimpan dalam kuki dan nilai baharu yang ditambah pada setiap respons menjadikan permintaan kemudiannya berkembang. Periksa Domain, Path, tamat tempoh dan tingkah laku pemadaman Set-Cookie; sahkan nama lama benar-benar tamat tempoh dan bukannya hanya ditulis ganti pada satu laluan sahaja. Pastikan token kebenaran pendek dan letakkan data boleh ubah dalam sesi bahagian pelayan yang dikawal atau stor selamat.

Langkah 4: Ambil kira lompatan proksi dan HTTP/2

Setiap lompatan mungkin mempunyai had agregat, setiap medan dan penimbal yang berbeza, manakala pemajuan menambah X-Forwarded-*, penjejakan dan medan pengesahan. Terbitkan bajet sebagai kontrak konfigurasi dan gunakan had terkecil sebagai had siling reka bentuk klien. HTTP/2 menggunakan HPACK untuk pemampatan pengangkutan, tetapi titik akhir masih menyahkod medan dan menguatkuasakan had; nisbah pemampatan tidak membuktikan pengepala perniagaan adalah selamat. Beri amaran tentang penolakan get laluan apabila aplikasi tidak menerima apa-apa.

Langkah 5: Pilih pemulihan dan pertahanan

Padamkan kuki pendua, kurangkan kandungan sesi, alihkan keadaan ke bahagian pelayan dan hantar hanya rujukan pendek yang tidak boleh diteka. Tetapkan dasar panjang token, putaran dan pembatalan; tolak medan tersuai yang tidak diketahui atau luar biasa besar. Tingkatkan had hanya selepas memeriksa memori penghuraian, keserentakan dan kos penafian perkhidmatan, dengan bajet setiap penyewa atau setiap laluan yang munasabah.

6. Contoh jawapan model

Saya akan mengenal pasti lompatan pertama yang mengembalikan 431 dan mengukur permintaan yang gagal selepas penyuntingan: jumlah bait pengepala, medan terbesar, baris permintaan, bilangan medan dan versi HTTP. Kegagalan pada pelayar sahaja pada mulanya menunjukkan kepada kuki pendua atau merentas subdomain, data sesi yang berkembang atau panjang kebenaran; menukar had asal sahaja adalah tidak selamat kerana CDN, pengimbang beban atau jaring perkhidmatan mungkin menolaknya lebih awal. Saya akan menamatkan tempoh kuki lama, meminimumkan keadaan klien, menggunakan rujukan sesi bahagian pelayan dan menyelaraskan bajet lompatan. Pemampatan pengangkutan HTTP/2 tidak menghapuskan had yang dinyahkod. Telemetri pengeluaran akan mengagregatkan persentil saiz mengikut lompatan dan nama medan sambil menyimpan panjang dan awalan cincangan, bukan kelayakan.

7. Kesilapan biasa

• Hanya mengosongkan kuki pelayar: Ia mungkin bersifat sementara; jejak penetap (setter), Domain, Path dan logik tamat tempoh untuk menghapuskan punca utama Set-Cookie pendua.
• Mengandaikan 431 sentiasa bermaksud 8 KB: RFC 6585 tidak menetapkan had sejagat; periksa setiap lapisan dan ukur bait.
• Hanya meningkatkan had asal: Pinggir atau get laluan masih boleh menolaknya terlebih dahulu, dan kos penghuraian meningkat; selaraskan bajet dan nilai kapasiti.
• Merekodkan pengepala permintaan lengkap: Ini mendedahkan kuki dan token; kekalkan nama, panjang, awalan cincangan dan ID korelasi.
• Mengandaikan pemampatan HTTP/2 menghapuskan had: Titik akhir menyahkod medan dan menguatkuasakan had; uji pemampatan pengangkutan secara berasingan daripada saiz yang dinyahkod.

8. Soalan susulan dan jawapan

Soalan susulan 1: Mengapakah curl berfungsi manakala pelayar gagal?

Pelayar secara automatik menghantar setiap kuki, pengesahan dan pengepala penjejakan yang sepadan dengan domain; curl biasanya lebih kecil. Eksport permintaan pelayar, alih keluar medan secara carian binari dan ukur setiap lompatan untuk memisahkan kandungan klien daripada had proksi.

Soalan susulan 2: Bolehkah JWT disimpan dalam kuki?

Boleh, tetapi setiap permintaan menanggung kos bait token tersebut dan beberapa kuki boleh melebihi had. Simpan rujukan pendek atau tuntutan (claims) minimum di bahagian klien, simpan data boleh ubah dan pembatalan di bahagian pelayan, serta kuat kuasakan bajet panjang dan putaran.

Soalan susulan 3: Bilakah meningkatkan had boleh diterima?

Hanya apabila keperluan itu benar-benar wujud, setiap lompatan boleh menyerap memori penghuraian dan keserentakan, serta ujian kapasiti, masa tamat (timeout) dan penafian perkhidmatan lulus. Kekalkan telemetri saiz, had kadar dan konfigurasi undur balik (rollback); had siling yang lebih tinggi bukanlah satu-satunya pembaikan.