Petunjuk dan ruang lingkup
Klien meminta resource menggunakan transparent content negotiation dan menerima HTTP 506 Variant Also Negotiates. Sistem memiliki negosiasi bergaya Apache, reverse proxy, dan cache. Jelaskan semantiknya, pemicu loop, diagnosis, perilaku cache, dan fallback.
Hal yang dievaluasi pewawancara
- Mengetahui bahwa 506 berasal dari transparent content negotiation RFC 2295.
- Membedakan loop negosiasi dari 406 Not Acceptable dan proxy 502.
- Memeriksa Alternates, Variant-Vary, TCN, dan metadata terkait.
- Menentukan batas retry, caching, dan downgrade.
- Menambahkan deteksi siklus, observabilitas, dan release gate.
Klarifikasi yang perlu ditanyakan terlebih dahulu
Konfirmasikan Accept dan Accept-Language, apakah resource berupa daftar varian, lapisan mana yang memancarkan 506, apakah cache proxy terlibat, dan apakah representasi tetap dapat diterima. Asumsikan sebuah varian menunjuk kembali ke resource yang sedang bernegosiasi.
Kerangka jawaban tiga puluh detik
506 berarti negosiasi transparan membentuk loop dan server tidak dapat memilih representasi akhir. Lacak rantai respons dan metadata negosiasi untuk membuktikan adanya siklus alih-alih menganggapnya sebagai kegagalan upstream generik. Klien tidak boleh melakukan retry secara membabi buta dengan konfigurasi yang sama; klien dapat meminta representasi tetap atau menonaktifkan negosiasi. Batasi kedalaman negosiasi, perbaiki varian, dan pantau 506 terhadap 406.
Pembahasan mendalam langkah demi langkah
1. Jelaskan negosiasi transparan
RFC 2295 memungkinkan origin memublikasikan varian, sementara klien dan perantara memilih representasi dari header permintaan. Permintaan pada akhirnya harus konvergen pada resource konkret.
2. Identifikasi loop
Jika sebuah varian menunjuk ke resource lain yang juga memerlukan negosiasi transparan, pemilihan dapat kembali ke objek awal. Catat URI resource, URI varian, proxy negosiasi, request id, dan visited set; mengunjungi kembali sebuah node membuktikan adanya siklus.
3. Bedakan kode status yang berdekatan
406 berarti tidak ada representasi yang memenuhi kondisi klien. 502 berarti gateway menerima respons upstream yang tidak valid. Investigasi 506 harus mengikuti graf negosiasi, bukan hanya status edge akhir.
4. Rancang fallback klien
Melakukan retry dengan header dan konfigurasi yang sama tidak dapat menghilangkan siklus. Minta varian tetap, hilangkan negosiasi transparan, atau tampilkan pesan perbaikan. Lakukan retry hanya dalam batas anggaran setelah perubahan konfigurasi atau sinyal transien yang eksplisit.
5. Tangani kunci cache dan Vary
Kunci cache harus menyertakan dimensi Vary yang digunakan dalam negosiasi; 506 tidak boleh menjadi jawaban jangka panjang untuk setiap representasi. Ikuti Cache-Control untuk caching error dan perhitungkan entri proxy lama setelah perbaikan.
6. Perbaiki dan amankan server
Bangun graf varian sebelum rilis dan jalankan deteksi siklus dengan batas kedalaman dan waktu. Kembalikan correlation id alih-alih topologi URI internal. Proxy mempertahankan status asli, Via, dan data trace agar penulisan ulang tidak menyembunyikan penyebabnya.
7. Validasi dan amati
Uji siklus mandiri (self-cycle), siklus dua node, daftar asiklik yang dalam, berbagai header Accept dan bahasa, cache proxy, rollout, serta rollback. Pantau 506/406, waktu negosiasi, fallback, cache hit, dan durasi perbaikan.
Contoh jawaban berkualitas tinggi
506 adalah error loop negosiasi transparan pada RFC 2295. Ketika sebuah varian menunjuk kembali ke resource yang bernegosiasi, server tidak dapat menghasilkan representasi akhir. Saya akan mencatat URI, varian, proxy, dan request id, menggunakan visited set untuk membuktikan siklus, serta mempertahankan status asli dan trace di setiap hop.
Kondisi yang sama harus fail-fast daripada melakukan retry. Klien dapat meminta varian tetap. Sebelum rilis, server membangun graf varian, memeriksa siklus, membatasi kedalaman dan waktu, serta memvalidasi Vary dan kunci cache. Pengujian penerimaan mencakup perubahan header dan bahasa, cache proxy, rollout, rollback, serta perbedaannya dengan 406.
Kesalahan umum
- Menganggap 506 sebagai 406 atau 502.
- Hanya memeriksa status akhir proxy alih-alih graf varian.
- Melakukan retry pada konfigurasi negosiasi yang sama secara terus-menerus.
- Menghilangkan dimensi Vary dari kunci cache.
- Merilis tanpa deteksi siklus dan batasan kedalaman.
- Mengembalikan URI varian internal dalam respons error.
Pertanyaan lanjutan dan jawabannya
Pertanyaan lanjutan 1: Apa perbedaan utama antara 506 dan 406?
406 berarti tidak ada representasi yang dapat diterima. 506 berarti proses negosiasi itu sendiri mengalami siklus dan tidak dapat konvergen.
Pertanyaan lanjutan 2: Bolehkah klien melakukan retry terhadap 506?
Tidak dengan konfigurasi yang tidak berubah. Lakukan retry hanya setelah perbaikan atau sinyal transien yang eksplisit, dalam batas anggaran tertentu.
Pertanyaan lanjutan 3: Bagaimana Anda membuktikan proxy mengubah status?
Bandingkan trace per-hop, Via, status asli, dan header negosiasi; reproduksi langsung ke origin jika diperlukan.
Pertanyaan lanjutan 4: Haruskah error di-cache?
Ikuti Cache-Control dan hindari memperkuat loop; bersihkan (purge) entri basi yang terpengaruh setelah perbaikan.