Temu duga umum: Bilakah HTTP 208 Already Reported patut digunakan, dan bagaimana anda mengelakkan penyalahgunaannya?

Gesaan dan skop

Perkhidmatan WebDAV membolehkan beberapa pengikatan menunjuk kepada sumber yang sama. Klien menghantar PROPFIND dengan Depth infinity, dan pelayan menemui sumber tersebut berulang kali dalam satu respons 207 Multi-Status. Terangkan 208 Already Reported, bila perlu mengeluarkannya, cara mengendalikan klien lama, dan bagaimana ia berbeza daripada 508 Loop Detected.

Ini ialah sambungan pengikatan WebDAV RFC 5842. 208 bukan kod kejayaan REST generik untuk "sudah wujud".

Perkara yang sedang diuji oleh penemu duga

Mengenal pasti 208 sebagai baris status di dalam respons 207 Multi-Status, bukan status respons HTTP kendiri.
Menghubungkan alias pengikatan, identiti sumber, dan penyenaraian berulang.
Membezakan sumber yang telah dilaporkan daripada gelung pengikatan sebenar dan menggunakan 508 dengan betul.
Mereka bentuk had Depth, pengendalian keupayaan klien, penghuraian XML, dan kebolehcerapan.

Soalan penjelasan

Adakah perkhidmatan ini melaksanakan kaedah pengikatan RFC 5842 dan DAV:resource-id?
Adakah klien memahami 208, atau hanya respons WebDAV 207 asas?
Adakah PROPFIND Depth bernilai 0, 1, atau infinity, dan apakah had pelayan yang dikenakan?
Adakah pengulangan disebabkan oleh pengikatan, pautan simbolik, atau kitaran induk-anak yang sebenar?
Adakah produk mesti menyenaraikan setiap alias, atau hanya melaporkan setiap sumber sekali sahaja?

Jawapan 30 saat

"208 menandakan sumber yang telah dilaporkan dalam respons 207 Multi-Status yang sama, biasanya apabila pengikatan WebDAV menyebabkan penyenaraian berulang. Saya menyahduplikasi berdasarkan identiti sumber yang stabil, mengembalikan propstat penuh untuk kemunculan pertama, dan menggunakan 208 untuk pengikatan seterusnya; gelung pengikatan yang tidak dapat ditamatkan dengan selamat ialah 508. Bagi klien yang tidak memahami 208, saya mengehadkan Depth atau mengembalikan 207 yang boleh dihuraikan dalam kontrak WebDAV, dan merekodkan sebab penyahduplikasian, kedalaman, gelung, dan pemangkasan. Saya tidak akan sesekali menggunakan 208 untuk hasil REST biasa 'sudah wujud'."

Reka bentuk langkah demi langkah

1. Sahkan lapisan respons

Respons HTTP luar biasanya ialah 207 Multi-Status. Setiap respons mengandungi URI sumber dan satu atau lebih elemen propstat. 208 ialah baris status di dalam respons sifat DAV yang berkaitan, menunjukkan bahawa sumber pengikatan telah pun dilaporkan dalam respons Multi-Status ini. Jangan gantikan 207 luar dengan 208.

2. Nyahduplikasi mengikut identiti sumber

URI tidak semestinya identiti sumber. Pengikatan yang berbeza boleh mendedahkan URI yang berbeza untuk satu sumber. Gunakan DAV:resource-id atau ID dalaman yang stabil untuk set yang telah dilawati bagi setiap traversal. Keluarkan sifat lengkap untuk pertemuan pertama, kemudian 208 untuk pengikatan seterusnya sambil mengekalkan hubungan setiap URI.

text

PROPFIND Depth: infinity
  /alias-a -> resource R: full propstat
  /alias-b -> resource R: 208 Already Reported
  /child   -> resource C: full propstat

3. Kekalkan 208 dalam konteks yang dimaksudkan

208 menjimatkan muatan sifat 207 yang berulang dan menghalang penyenaraian pengikatan daripada berkembang tanpa had. Ia tidak bermaksud konflik sisipan pangkalan data, percubaan semula idempoten berjaya, atau capaian cache. API JSON biasa sebaliknya harus memilih semantik 200, 201, 204, atau 409 yang eksplisit.

4. Bezakan 508 Loop Detected

Jika traversal mendapati hubungan pengikatan yang membentuk kitaran dan bukannya rujukan kedua kepada sumber yang telah selesai, hentikan rekursi dan gunakan 508 Loop Detected. 208 bermaksud sumber telah berjaya dilaporkan lebih awal; 508 bermaksud pemprosesan telah dihentikan untuk mengelakkan gelung tak terhingga. Uji alias, kitaran sebenar, dan had kedalaman secara berasingan.

5. Kendalikan keserasian dan had sumber

Rundingkan atau perhatikan sokongan klien untuk 208. Untuk klien lama, hadkan Depth infinity, tolak permintaan yang tidak selamat, atau kembalikan kandungan propstat yang boleh difahami tanpa melanggar semantik WebDAV. Hadkan bilangan nod, bait respons, masa, dan memori set yang dilawati supaya graf pengikatan berniat jahat tidak dapat menghabiskan sumber perkhidmatan.

6. Perhatikan dan pulihkan

Rekodkan ID permintaan, Depth, bilangan sumber yang dilawati, kiraan 208, kiraan 508, sebab pemangkasan, saiz respons, dan keupayaan klien; jangan sekali-kali log kandungan fail atau kelayakan. Jika indeks penyahduplikasian gagal, pangkas dengan selamat menggunakan ralat yang jelas dan bukannya mengeluarkan rekursi tanpa batas. Kekalkan graf pengikatan yang boleh dihasilkan semula untuk penyahpepijatan identiti dan gelung.

Model jawapan berkualiti tinggi

"Respons luar kekal 207 Multi-Status; 208 muncul dalam status propstat untuk menyatakan bahawa sumber yang sama telah dilaporkan. Untuk PROPFIND Depth infinity, saya membina set yang dilawati daripada identiti sumber: pengikatan pertama mengembalikan sifat penuh, dan alias seterusnya mengembalikan 208 sambil mengekalkan URI mereka. Kitaran sebenar berhenti dengan 508. Saya tidak akan menggunakan 208 untuk hasil already-exists atau percubaan semula API generik. Klien lama menerima had kedalaman atau penolakan yang selamat, dan telemetri merangkumi sumber, saiz respons, 208, 508, dan pemangkasan."

Kesilapan biasa

Menetapkan keseluruhan respons HTTP kepada 208 → struktur 207 Multi-Status hilang → letakkan 208 dalam status propstat yang berkaitan.
Menggunakan URI sebagai kunci sumber → alias masih menduplikasi sumber → nyahduplikasi mengikut ID sumber.
Menggunakan 208 untuk already-exists → klien REST generik salah mentafsirkannya → gunakan 409 atau respons perniagaan yang eksplisit.
Menganggap setiap duplikasi sebagai 508 → alias biasa kelihatan seperti gelung → asingkan sumber yang dilaporkan daripada kitaran.
Tidak menetapkan had Depth atau respons → graf pengikatan boleh menghabiskan memori → hadkan nod, masa, bait, dan saiz set yang dilawati.

Soalan susulan dan respons

Adakah entri 208 masih memerlukan URI?

Ya. Kekalkan respons untuk pengikatan tersebut supaya klien mengetahui URI mana yang telah dilalui, tetapi jangan ulangi muatan sifat yang lengkap. XML mesti mengikut kontrak penghuraian Multi-Status WebDAV.

Mengapa tidak memadamkan terus entri pendua?

Pemadaman menyembunyikan fakta bahawa alias telah dilalui dan mungkin kelihatan seperti peninggalan pelayan. 208 mengekalkan bukti traversal di samping mengelakkan data sifat pendua.

Bilakah pelayan patut menolak Depth infinity?

Tolak atau hadkannya apabila klien tidak dapat menghuraikan 208, graf pengikatan melebihi had sumber, atau set yang dilawati yang boleh dipercayai tidak dapat dibina. Respons yang terhad adalah lebih selamat daripada output yang tidak lengkap atau rekursi tanpa had.