Prompt dan latar situasi
Server menolak untuk menginterpretasikan request target karena URI-nya lebih panjang dari batas yang dikonfigurasi. Kegagalan ini dapat berasal dari serialisasi klien, perulangan pengalihan (redirect loops), cookie, atau batasan proxy, sehingga hanya menaikkan batas pada satu server mungkin tidak menyelesaikannya.
Apa yang diuji oleh pewawancara
- Menemukan komponen permintaan mana yang melampaui batas pada hop mana.
- Mempertahankan semantik metode HTTP saat memindahkan data dari URI ke body.
- Merancang kontrak query yang berbatas (bounded) dan dapat diobservasi, alih-alih menerima URL arbitrer.
Pertanyaan klarifikasi sebelum menjawab
- Apakah panjang berlebih tersebut berada di path, query, lokasi pengalihan (redirect), atau blob status klien yang dienkode?
- Hop mana yang mengembalikan 414: browser, CDN, load balancer, gateway, atau origin?
- Apakah operasi ini aman (safe) dan dapat di-cache, atau apakah operasi ini mengubah status (mutates state)?
- Apakah klien memerlukan URL yang dapat dibagikan, kemampuan bookmark, atau privasi untuk set filter tersebut?
Kerangka jawaban 30 detik
Saya akan mencatat panjang request target dan hop yang menghasilkan 414, kemudian memeriksa pengalihan, cookie, encoding, dan serialisasi filter. Untuk pencarian read-only dengan set filter yang terlalu besar, saya akan menggunakan endpoint pencarian POST yang berbatas atau token kueri sisi server berumur pendek, mendokumentasikan batasan, dan mempertahankan otorisasi. Saya tidak akan sekadar menaikkan satu batas proxy tanpa menguji setiap hop serta memeriksa implikasinya terhadap log dan cache.
Pembahasan mendalam langkah demi langkah
1. Mengukur request target yang sebenarnya
Catat metrik panjang yang aman, template rute, jumlah pengalihan, dan correlation ID tanpa mencatat nilai kueri yang sensitif. Bandingkan batas browser, CDN, gateway, dan origin. Blob status base64, parameter berulang, atau redirect loop yang tidak disengaja dapat memperbesar URI sebelum kode aplikasi berjalan.
2. Mempertahankan semantik metode dan cache
GET bersifat aman dan secara alami dapat di-cache, tetapi URL bukanlah sarana transportasi data tanpa batas. Memindahkan set filter yang besar ke POST akan mengubah perilaku cache dan bookmark, jadi tentukan endpoint yang eksplisit, kebijakan cache respons, dan ekspektasi idempotensi. Jangan menggunakan POST hanya untuk menyembunyikan mutasi di balik rute pencarian.
3. Membatasi dan menormalisasi filter
Tetapkan batasan pada jumlah predikat, panjang nilai, kedalaman nesting, dan total byte yang dienkode. Tolak parameter yang salah format atau duplikat secara konsisten. Buat filter yang ekuivalen menjadi kanonikal (canonicalize) agar cache dan tanda tangan tidak memperlakukan perbedaan urutan yang sepele sebagai permintaan yang berbeda.
4. Menggunakan token kueri saat kemampuan berbagi itu penting
Simpan objek filter yang telah dinormalisasi di sisi server dengan TTL yang pendek, otorisasi tenant dan pengguna, serta pengambilan satu kali atau berbayup (scoped). Kembalikan token pendek yang dapat ditempatkan di URL. Jangan pernah memasukkan rahasia atau data pribadi mentah ke dalam token atau query string; terapkan kedaluwarsa dan pencabutan (revocation).
5. Memperlakukan 414 sebagai sinyal operasional
Pasang peringatan (alert) pada tingkat kemunculan berdasarkan rute, versi klien, dan hop proxy. Lacak rantai pengalihan dan perubahan deployment yang mengubah serialisasi. Fallback yang aman dapat meminta pengguna untuk mengurangi filter atau mengirimkan formulir melalui endpoint body; jangan memotong (truncate) kriteria secara diam-diam.
Contoh jawaban berkualitas tinggi
“Saya pertama-tama akan mengukur panjang target dan mengidentifikasi hop mana yang menghasilkan 414, kemudian memeriksa pengalihan, cookie, encoding, dan filter yang berulang. Untuk pencarian read-only yang set filternya melebihi batas URL, saya akan menambahkan endpoint pencarian POST yang berbatas atau token kueri berumur pendek yang terotorisasi, dengan semantik cache dan audit yang eksplisit. Saya akan membatasi predikat dan byte yang dienkode, tidak pernah memotong secara diam-diam, dan memantau tingkat 414 berdasarkan rute dan versi klien. Menaikkan satu batas proxy hanya boleh dilakukan sebagai perubahan yang terkoordinasi dan teruji di setiap hop.”
Kesalahan umum
- Hanya menaikkan batas origin → CDN atau gateway mungkin masih menolak permintaan → ukur dan konfigurasikan setiap hop.
- Memindahkan data ke POST tanpa membahas kemampuan cache (cacheability) → klien kehilangan semantik yang diharapkan → definisikan perilaku cache, pembagian, dan idempotensi.
- Memotong filter yang terlalu besar → hasilnya tidak lagi menjawab kueri pengguna → tolak dengan jelas atau gunakan endpoint alternatif yang berbatas.
- Menaruh rahasia di dalam token kueri → URL bocor melalui log dan perujuk (referrer) → batasi cakupan (scope), kedaluwarsa, dan otorisasi token buram (opaque).
Pertanyaan lanjutan dan tanggapan
Apakah 414 hanya disebabkan oleh query string?
Tidak. Request target mencakup path dan query, dan pengalihan (redirect) dapat membuat target menjadi terlalu besar. Cookie memengaruhi batas header alih-alih URI itu sendiri, sehingga diagnostik harus mengidentifikasi komponen pasti yang ditolak.
Haruskah setiap GET berukuran besar diubah menjadi POST?
Tidak. Pertahankan GET untuk pembacaan biasa yang aman dan dapat di-cache. Gunakan POST untuk kontrak pencarian yang sengaja didefinisikan ketika representasi permintaan tidak dapat memenuhi batas URI praktis, dan dokumentasikan perubahan perilaku cache dan pembagiannya.
Mengapa tidak menaikkan semua batas secara drastis?
Target yang besar menghabiskan sumber daya parser, logging, cache, dan keamanan serta dapat menciptakan batasan yang tidak konsisten antar hop. Naikkan batas hanya jika ada kebutuhan yang terukur, konfigurasi yang terkoordinasi, dan pengujian penyalahgunaan (abuse testing).