Topik wawancara representatif

Wawancara umum: Kapan HTTP 508 Loop Detected harus dikembalikan, dan bagaimana klien harus memulihkan diri?

UmumSedang
Tim Redaksi Offer.ccDipublikasikan Diperbarui

Pertanyaan

Sebuah klien WebDAV mengirimkan PROPFIND dengan Depth: infinity untuk koleksi bersama, dan server menemukan siklus binding. Jelaskan mengapa server mengembalikan 508, kapan 208 sesuai, cara membatasi biaya traversal, dan bagaimana klien harus memulihkan diri dengan aman.

Perintah dan cakupan

Sumber daya WebDAV dapat muncul di beberapa jalur melalui binding. Oleh karena itu, traversal koleksi rekursif dapat mengunjungi kembali sumber daya yang sama atau mengikuti siklus selamanya. RFC 5842 mendefinisikan 208 Already Reported untuk anggota yang sudah dilaporkan dalam respons multistatus yang sama dan 508 Loop Detected ketika operasi dihentikan setelah menemukan loop.

Hal yang diuji oleh pewawancara

  • Apakah Anda menempatkan 508 dalam konteks WebDAV dan bukan memperlakukannya sebagai kesalahan gateway generik.
  • Apakah Anda membedakan 208 untuk anggota yang sudah dilaporkan dari 508 untuk operasi yang dihentikan.
  • Apakah kedalaman, jumlah node, waktu, dan byte respons menjadi anggaran yang dapat ditegakkan.
  • Apakah perilaku klien bersifat idempoten, dapat diobservasi, dan bebas dari percobaan ulang tanpa akhir.

Pertanyaan klarifikasi

  • Apakah metodenya adalah PROPFIND, dan apakah Depth diatur ke infinity?
  • Apakah sumber daya mendukung binding DAV, dan apakah klien memahami 208?
  • Haruskah server mengembalikan seluruh pohon, hasil yang dibatasi, atau hanya kedalaman terbatas?
  • Apakah koleksi tersebut bersifat lintas-penyewa (cross-tenant), dan properti apa saja yang boleh diungkapkan?

Jawaban 30 detik

Pertama-tama saya akan mengonfirmasi siklus binding WebDAV dan bukan pengalihan HTTP biasa. Selama traversal, saya akan melacak ID sumber daya yang stabil dan menerapkan anggaran untuk kedalaman, node, waktu, dan byte respons. Jika klien memahami 208, anggota yang sudah dilaporkan dapat direpresentasikan sebagaimana mestinya; ketika traversal kembali ke tumpukan rekursi aktif dan tidak dapat selesai dengan aman, server menghentikan operasi dengan 508 dan badan kesalahan yang stabil. Klien tidak boleh mencoba ulang permintaan kedalaman tak terbatas yang sama secara membabi buta; klien harus mengurangi kedalaman atau meminta agar binding diperbaiki.

Jawaban mendalam

1. Tentukan batas 508

508 berarti bahwa server menghentikan operasi WebDAV karena menemukan loop saat memproses semantik kedalaman tak terbatas. Ini bukan kode generik untuk disk penuh, batas waktu upstream, atau setiap kegagalan rekursif. Badan kesalahan dapat mencakup kode stabil dan ID permintaan, tetapi tidak boleh mengekspos jalur penyewa lain atau topologi internal.

2. Lacak identitas binding

Gunakan resource-id DAV atau identitas sumber daya stabil lainnya saat melakukan traversal alih-alih hanya membandingkan URL saat ini. Satu sumber daya dapat memiliki beberapa jalur, sehingga deduplikasi hanya-URL akan melewatkan alias; identitas stabil mendeteksi anggota yang berulang tanpa memperlakukan alias yang valid sebagai sebuah siklus.

3. Memilih antara 208 atau 508

Ketika semantik klien dan respons memungkinkannya, anggota yang sudah ada dalam hasil multistatus yang sama dapat ditandai 208 sementara anggota lain yang dapat dijangkau terus diproses. Jika traversal kembali ke sumber daya dalam tumpukan rekursi aktif dan operasi tidak dapat dilanjutkan dengan aman, hentikan dan kembalikan 508. Maknanya masing-masing adalah "sudah dilaporkan" dan "dihentikan karena loop".

4. Terapkan anggaran sumber daya

Bahkan graf asiklik memerlukan batasan untuk kedalaman maksimum, node unik, tumpukan rekursi, byte respons, dan waktu jam dinding (wall-clock time). Saat anggaran habis, gunakan kesalahan aplikasi yang stabil atau kebijakan hasil terbatas dan catat alasannya. Jangan biarkan koleksi besar menghabiskan CPU, memori, atau bandwidth jaringan tanpa batas.

5. Rancang pemulihan klien

Setelah 508, klien harus mempertahankan ID permintaan dan konteks sumber daya serta berhenti mencoba ulang secara otomatis permintaan kedalaman tak terbatas yang sama. Klien dapat menggunakan kedalaman terbatas, pembacaan tersegmentasi, atau menunggu administrator memperbaiki binding. Nilai Retry-After, jika disediakan, bukanlah bukti bahwa siklus telah hilang.

6. Konkurensi dan caching

Traversal bersamaan dari graf yang sama masih memerlukan anggaran per permintaan dan pembatalan. Cache dapat mengurangi pembacaan properti, tetapi tidak dapat melewati otorisasi atau menggunakan kembali graf satu penyewa untuk penyewa lain. Setelah siklus diperbaiki, batalkan validitas cache dan ringkasan yang terpengaruh berdasarkan versi atau token perubahan.

7. Verifikasi dan observabilitas

Uji self-binding, siklus dua node, alias, kedalaman terbatas dan tak terbatas, klien yang tidak memahami 208, kehabisan anggaran, race condition pembatalan, dan perubahan izin. Pantau siklus yang terdeteksi, node unik, waktu traversal, byte respons, tingkat 508, tingkat 208, dan percobaan ulang, yang disegmentasikan berdasarkan penyewa.

Jawaban model

508 adalah hasil eksplisit dari penghentian traversal binding WebDAV setelah menemukan siklus. Saya akan mempertahankan tumpukan rekursi aktif dan kumpulan yang sudah dilaporkan menggunakan ID sumber daya yang stabil; anggota yang sudah dilaporkan dapat menggunakan 208 jika klien mendukungnya, sedangkan kembali ke tumpukan aktif menghasilkan 508. Setiap permintaan memiliki anggaran kedalaman, node, waktu, dan byte, dan badan kesalahan hanya berisi kode stabil dan ID permintaan. Klien berhenti mencoba ulang permintaan kedalaman tak terbatas yang sama dan beralih ke traversal terbatas atau perbaikan binding. Uji beban mencakup siklus, alias, izin, dan pembatalan, dengan metrik siklus, anggaran, dan percobaan ulang.

Kesalahan umum

  • Memperlakukan 508 seperti 5xx lainnya → Klien tidak dapat memilih perbaikan yang tepat sasaran → Gunakan untuk konteks binding-loop.
  • Melakukan deduplikasi berdasarkan URL → Alias terlewat atau salah diklasifikasikan → Gunakan identitas sumber daya yang stabil.
  • Memperlakukan 208 sebagai kesalahan loop → Anggota yang dilaporkan disalahartikan sebagai penghentian → 208 berarti anggota tersebut sudah dilaporkan.
  • Mencoba ulang 508 selamanya → Masalah direktori terus menghabiskan sumber daya → Kurangi kedalaman atau perbaiki binding.

Pertanyaan lanjutan

Bisakah 208 dan 508 muncul dalam respons yang sama?

Ya. Beberapa anggota mungkin ditandai 208 karena sudah dilaporkan sebelumnya; siklus berikutnya masih dapat menyebabkan operasi keseluruhan dihentikan dengan 508. Struktur respons harus mengikuti semantik multistatus WebDAV.

Apakah batas kedalaman rekursi sudah cukup?

Tidak. Koleksi yang lebar dan dangkal masih dapat menghasilkan banyak node dan respons yang besar, jadi batasi juga node unik, byte, CPU, dan waktu jam dinding.

Haruskah reverse proxy menulis ulang 508 menjadi 500?

Biasanya tidak. Pertahankan status dan bidang kesalahan yang stabil. Jika kontrak eksternal memerlukan pemetaan, pertahankan penyebab asli dalam log dan pastikan klien tetap berhenti mencoba ulang.

Bagaimana Anda membuktikan alias tetap berfungsi setelah perbaikan?

Uji graf asiklik dengan binding bersama: ID sumber daya yang sama yang dijangkau melalui beberapa jalur harus menghasilkan 208 atau deduplikasi yang setara, sementara otorisasi tetap diperiksa secara independen untuk setiap jalur.

Sumber publik

Pertanyaan terkait