Wawancara umum: Kapan HTTP 508 Loop Detected tepat digunakan, dan bagaimana Anda mencegah siklus traversal WebDAV?

Konteks dan cakupan

Layanan WebDAV memungkinkan beberapa binding antar koleksi. Klien mengirimkan PROPFIND dengan Depth: infinity; server mencapai koleksi yang sudah berada di jalur traversal dan mengembalikan 508. Jelaskan arti persis dari 508, bedakan dari perulangan percobaan ulang (retry loop) generik, jelaskan kapan 208 Already Reported tepat digunakan, cegah habisnya sumber daya (resource exhaustion), dan tentukan perilaku klien.

Ini menggabungkan semantik status HTTP, traversal graf, kompatibilitas protokol, dan batasan keamanan. RFC 5842 mendefinisikan 508 untuk menghentikan operasi kedalaman tak terbatas setelah sebuah loop ditemui; IANA mendaftarkan 508 di bawah RFC 5842.

Apa yang sedang diuji oleh pewawancara

Apakah Anda mengetahui bahwa 508 berkaitan dengan binding WebDAV dan Depth: infinity, bukan sembarang kegagalan pengalihan (redirect).
Apakah Anda dapat memodelkan sumber daya, binding URI, jalur, dan koleksi yang dikunjungi sebagai graf.
Apakah Anda membedakan antara melanjutkan dengan 208 untuk sumber daya yang berulang versus menggagalkan seluruh operasi dengan 508 ketika klien tidak memiliki dukungan 208.
Apakah Anda menyediakan penghentian deterministik, anggaran (budget), observabilitas, dan fallback alih-alih hanya mengatakan "tambahkan visited set."

Pertanyaan untuk diklarifikasi terlebih dahulu

Metode dan nilai Depth apa yang digunakan? Semantik ini berkaitan dengan traversal rekursif.
Apakah server mengimplementasikan binding RFC 5842 dan mengiklankan kapabilitas DAV? Apakah klien memahami 208?
Apakah sebuah simpul dideplikasi berdasarkan ID sumber daya, URI kanonis, atau jalur binding? Satu sumber daya dapat memiliki beberapa URI.
Apakah respons harus berisi hasil parsial, atau operasi harus gagal secara atomik?
Batasan anggaran simpul, ukuran body, waktu CPU, dan otorisasi apa yang membatasi traversal dalam yang berbahaya?

Kerangka jawaban 30 detik

Pertama batasi artinya: 508 menyatakan bahwa server menghentikan operasi WebDAV Depth: infinity setelah menemukan siklus binding; ini bukan status coba lagi HTTP generik. Modelkan binding sebagai graf dan deteksi back edge berdasarkan identitas sumber daya. Jika klien memahami 208, laporkan sumber daya satu kali dan lanjutkan respons multistatus; jika tidak, 508 dapat menggagalkan operasi secara jelas. Terapkan anggaran simpul, kedalaman, byte, dan waktu, catat siklusnya, dan hentikan percobaan ulang otomatis oleh klien.

Jawaban langkah demi langkah

1. Modelkan graf sumber daya, bukan hanya string URL

Simpul adalah sumber daya atau koleksi dan tepi adalah binding. URI adalah jalur akses, belum tentu merupakan identitas sumber daya; satu sumber daya dapat memiliki beberapa binding. Simpan ID sumber daya, jalur saat ini, dan jalur induk untuk deduplikasi, audit, dan diagnosis.

2. Gunakan status DFS atau BFS eksplisit

Pertahankan stack rekursi aktif dan set yang dilaporkan (reported set). Sebelum memasuki sebuah simpul, periksa apakah simpul tersebut sudah ada di stack aktif; itu adalah back edge. Mencapai sumber daya yang sama melalui jalur lain dapat diperlakukan sebagai sudah dilaporkan sesuai kapabilitas protokol alih-alih diekspansi selamanya.

text

visit(node, path):
  if node in activePath: return CYCLE
  if node in reported: return ALREADY_REPORTED
  budget.consume(node)
  activePath.add(node)
  report(node)
  for child in children(node): visit(child, path + child)
  activePath.remove(node)

activePath mengidentifikasi siklus nyata, sedangkan reported mencegah keluaran duplikat melalui beberapa binding. Satu set tidak dapat mewakili kedua kasus tersebut secara aman.

3. Pilih 208 atau 508 dari kapabilitas klien

Jika klien mengiklankan dukungan untuk ekstensi binding dan 208, server dapat mengembalikan kemunculan pertama secara normal, menandai binding selanjutnya sebagai Already Reported dalam respons multistatus, dan menghilangkan turunan (descendants) mereka. Jika klien tidak memahami 208, RFC 5842 menyediakan jalur kompatibilitas di mana operasi kedalaman tak terbatas gagal dengan 508. Jangan menyamarkan kegagalan sebagai 200.

4. Tetapkan anggaran deterministik dan batas keamanan

Bahkan graf asiklik dapat menghabiskan CPU, memori, atau ruang respons. Tetapkan simpul maksimum, panjang jalur aktif, total byte, waktu aktual (wall-clock time), dan konkurensi. Saat anggaran habis, catat alasannya dan kembalikan kegagalan yang diizinkan secara jelas alih-alih mencoba lagi. Periksa otorisasi di seluruh binding tenant sehingga simpul tersembunyi tidak bocor melalui respons multistatus.

5. Tangani operasi tulis dan perubahan topologi yang bersamaan

BIND, REBIND, dan UNBIND mengubah graf. Lakukan traversal pada snapshot atau versi yang konsisten sehingga perubahan topologi tidak membatalkan deteksi di tengah operasi. Sebelum membuat binding yang mungkin siklik, jalankan pemeriksaan keterjangkauan (reachability check) atau wajibkan prakondisi eksplisit yang mengizinkan siklus; pertahankan pemeriksaan dan commit dalam satu batas transaksi.

6. Buat klien menghentikan percobaan ulang yang berbahaya

508 berarti operasi yang diminta gagal; klien tidak boleh memperlakukannya seperti 503 dan mencoba lagi secara membabi buta dengan backoff. Baca body dan ID korelasi, kurangi kedalaman, perbaiki binding, atau kueri kapabilitas. Proksi yang memetakan 508 ke dalam kesalahan umum harus mempertahankan status asli dan bidang diagnostik.

Contoh jawaban berkualitas tinggi

Saya akan memodelkan binding sebagai graf berarah dan membedakan identitas sumber daya dari URI akses. Untuk Depth: infinity, gunakan stack rekursi aktif untuk mendeteksi back edge dan set yang dilaporkan untuk menekan keluaran duplikat ketika beberapa binding mencapai sumber daya yang sama; set tersebut memiliki arti yang berbeda. Telusuri tampilan yang konsisten dengan anggaran simpul, kedalaman, byte respons, dan waktu.

Ketika klien mengiklankan dukungan RFC 5842 dan 208, kembalikan sumber daya pertama dalam respons multistatus 207, tandai duplikat berikutnya sebagai Already Reported, dan hilangkan turunannya. Untuk klien yang tidak memahami 208, hentikan seluruh operasi kedalaman tak terbatas dengan 508 sebagaimana ditentukan oleh jalur kompatibilitas. 508 bukan kesalahan coba lagi generik, jadi klien harus menghentikan percobaan ulang otomatis dan memperbaiki graf atau menurunkan kedalaman. Terapkan otorisasi, metrik, dan log korelasi untuk menjaga agar siklus dan traversal yang dalam tidak menjadi vektor DoS.

Pola kegagalan umum

Menyebut 508 sebagai kehabisan percobaan ulang reverse-proxy atau loop pengalihan URL generik.
Melakukan deduplikasi hanya dengan string URI dan melewatkan beberapa binding ke satu sumber daya.
Hanya menggunakan global visited set, membingungkan sumber daya bersama dengan back edge, atau kehilangan perbedaan 208/508.
Menerima Depth: infinity tanpa anggaran simpul, byte, waktu, dan otorisasi.
Mencoba ulang 508 secara otomatis dan menghabiskan sumber daya berulang kali pada topologi yang sama.
Melupakan negosiasi kapabilitas, respons multistatus 207, atau race condition pada operasi tulis.

Pertanyaan lanjutan dan referensi jawaban

Apa batas antara 508 dan 208?

208 melaporkan sumber daya yang dilihat sebelumnya ketika klien memahami ekstensi binding, memungkinkan sisa operasi berlanjut. 508 menghentikan seluruh operasi kedalaman tak terbatas setelah terjadi siklus, biasanya untuk klien yang tidak dapat menggunakan 208.

Mengapa tidak menggunakan URI saja sebagai visited key?

Beberapa URI dapat terikat pada satu sumber daya, sehingga pelacakan hanya-URI akan mengulangi traversal. Jalur tetap penting untuk diagnosis, jadi simpan identitas sumber daya dan konteks jalur.

Bagaimana Anda menghindari TOCTOU antara pemeriksaan dan penulisan?

Jalankan validasi keterjangkauan dan commit binding dalam satu transaksi atau snapshot berversi. Jika atomisitas mencakup beberapa simpul, gagalkan pada kondisi versi dan periksa kembali.

Haruskah klien mencoba lagi setelah 508?

Tidak secara membabi buta. Topologi saat ini membuat operasi gagal; kurangi kedalaman, perbaiki siklus, atau dapatkan informasi kapabilitas. Coba lagi hanya setelah topologi diubah secara sengaja.

Bagaimana Anda menguji deteksi siklus false-positive?

Gunakan fixture untuk DAG asiklik, sumber daya bersama, siklus binding, dan batas kedalaman. Lakukan assert pada jumlah hasil, kode status, anggaran traversal, log audit, dan batas ukuran respons.

Apakah 508 berlaku untuk setiap siklus panggilan microservice?

Tidak. Arti standarnya berasal dari WebDAV RFC 5842. Loop layanan lain memerlukan kontrak kesalahannya sendiri; mempertahankan 5xx tidak membuat respons memiliki semantik WebDAV 508.