Gesaan dan skop
Perkhidmatan fail kolaboratif menyokong WebDAV dan membolehkan pelanggan mengedit sumber yang sama. Operasi tulis, alih atau padam kadangkala mengembalikan 423 Locked. Terangkan sempadan antara 423, 409, dan 403; bagaimana pelanggan memperoleh dan menghantar token kunci; cara mengendalikan depth, timeout, pembaharuan, dan ranap pemilik; serta cara menjadikan pemulihan boleh diperhatikan (observable).
Perkara yang diuji oleh penemu duga
- Sama ada anda menerangkan 423 sebagai kunci yang menyekat sumber sasaran dan bukannya ralat konkurensi generik.
- Sama ada anda memahami Lock-Token, If, Timeout, dan UNLOCK secara bersepadu.
- Sama ada anda boleh mereka bentuk pajakan (leases), pemulihan sambungan semula, dan kebenaran tanpa kunci kekal atau pembukaan kunci yang tidak disengajakan.
- Sama ada pelanggan boleh membezakan antara menunggu, memperoleh semula, dan kegagalan yang tidak boleh dicuba semula.
Soalan untuk dijelaskan terlebih dahulu
- Adakah kunci itu kunci tulis WebDAV, pajakan penyuntingan aplikasi, atau kedua-duanya?
- Adakah ia merangkumi satu sumber atau koleksi kedalaman infiniti (infinity-depth), dan bagaimanakah elemen anak mewarisi atau menarik diri?
- Di manakah token disimpan, dan adakah ia terikat pada penyewa (tenant), prinsipal, versi sumber, dan kebenaran?
- Siapa yang memperbaharui dan menuntutnya semula selepas pemutusan sambungan, proses ranap, atau herotan jam (clock skew)?
- Bolehkah proksi mencuba semula penulisan, dan bolehkah pelanggan memainkan semula (replay) badan permintaan dengan selamat?
Jawapan 30 saat
423 menyatakan bahawa kunci sedang menghalang kaedah daripada digunakan pada sasaran; ia bukan penolakan kebenaran generik atau setiap konflik versi. Saya akan menetapkan skop, pemilik, dan baki pajakan, kemudian memerlukan Lock-Token yang sepadan dalam syarat If. Perkhidmatan memiliki pajakan dan menggunakan masa monotonik; pembaharuan dibenarkan dan dihadkan, manakala tamat tempoh menuntut semula kunci selepas ranap berlaku. Pelanggan menganggap 423 sebagai menunggu terkawal atau pemerolehan semula, tidak sekali-kali memainkan semula penulisan bukan idempoten secara membuta tuli.
Analisis terperinci langkah demi langkah
Langkah 1: Tentukan sempadan protokol
RFC 4918 menggunakan 423 apabila kaedah tidak boleh digunakan pada sumber yang dikunci. 403 adalah mengenai kebenaran dan 409 mengenai konflik dengan keadaan semasa, jadi kelaskan punca sekatan sebelum memilih status.
Langkah 2: Tentukan identiti dan skop kunci
Simpan identiti sumber, punca kunci (lock root), kedalaman (depth), pemilik, token, masa penciptaan, pajakan, domain kebenaran, dan versi sumber. Kunci infinity-depth boleh merangkumi elemen anak, jadi pelayan menyelesaikan pewarisan sebelum setiap penulisan dan bukannya hanya menyemak URL.
Langkah 3: Sahkan Lock-Token
Pelanggan memperoleh token dengan LOCK dan menghantarnya dalam syarat If pada permintaan tulis, alih, atau padam yang seterusnya. Pelayan menyemak token, skop, prinsipal, dan penyewa. Token yang hilang, tidak sah bentuknya, atau milik pihak luar akan menerima kegagalan yang boleh didiagnosis tanpa mendedahkan pemilik penyewa lain.
Langkah 4: Gunakan pajakan untuk tamat masa dan pembaharuan
Timeout ialah nilai yang diminta, bukan kebenaran untuk pelanggan membuat pajakan tanpa had. Pelayan menyimpan tamat tempoh menggunakan jam monotonik, mengesahkan pembaharuan, dan mengehadkan tempoh maksimum. Respons menyatakan tamat masa yang diberikan, dan pelanggan menjadualkan pembaharuan daripada nilai tersebut. Tamat tempoh menuntut semula kunci selepas ranap.
Langkah 5: Kendalikan pemutusan sambungan dan pemulihan
Selepas menyambung semula, pemilik menanyakan status kunci dan memperbaharui hanya dengan token yang masih sah; cache tempatan tidak dapat membuktikan pemilikan. Mulakan semula (restart) memulihkan pajakan daripada storan tahan lama (durable storage). Jika pemulihan selamat tidak dapat dibuktikan, batalkan kunci dan wajibkan pemerolehan semula supaya token lama tidak boleh menulis.
Langkah 6: Asingkan menunggu daripada mencuba semula
Pelanggan boleh menunjukkan status "sumber sedang diedit" tanpa mengira pemegang dan melakukan tinjauan (polling) dengan penangguhan (backoff) berdasarkan baki pajakan. 423 bukan kegagalan rangkaian sementara. Cuba semula penulisan hanya apabila token, versi, dan badan permintaan disahkan boleh dimainkan semula; proksi tidak boleh memainkan semula permintaan bukan idempoten dengan hasil pelaksanaan yang tidak diketahui.
Langkah 7: Pantau dan kawal penyalahgunaan
Rekod cincangan (hash) sumber, skop kunci, baki pajakan, sebab kegagalan, cincangan prinsipal, dan ID permintaan. Ukur kadar 423, tempoh pegangan, kegagalan pembaharuan, penuntutan semula tamat tempoh, dan bilangan depth-lock mengikut penyewa, jenis sumber, dan versi pelanggan. Hadkan bilangan depth-lock, pajakan maksimum, dan percubaan token untuk membendung keletihan sumber dan tekaan token.
Contoh jawapan berkualiti tinggi
Saya terlebih dahulu akan membuktikan bahawa 423 ialah kunci WebDAV, mengasingkannya daripada kebenaran 403 dan konflik keadaan aplikasi 409. Perkhidmatan kunci menyimpan sumber, kedalaman, prinsipal, penyewa, Lock-Token, pajakan yang diberikan, dan versi secara tahan lama. Pelanggan memperoleh token dengan LOCK dan menyerahkannya dalam If; pelayan mengesahkan token, skop, prinsipal, dan kebenaran secara bersama. Pajakan menggunakan masa monotonik bahagian pelayan dan tempoh maksimum. Selepas pemutusan sambungan, pelanggan hanya boleh memperbaharui dengan token yang sah; selepas ranap, tamat tempoh menuntut semula kunci tersebut. Pelanggan memaparkan keadaan diduduki-penyuntingan yang boleh dipulihkan, melakukan tinjauan dengan backoff, dan tidak pernah mencuba semula penulisan dengan hasil yang tidak diketahui secara membuta tuli. Telemetri pengeluaran merangkumi kadar 423, tempoh pegangan, kegagalan pembaharuan, penuntutan semula, dan bilangan depth-lock, dengan ujian untuk pelanggan yang bersaing, mula semula, herotan jam, dan cubaan semula proksi.
Kesilapan biasa
- Mengembalikan 423 untuk setiap konflik konkurensi dan menyembunyikan ralat versi atau kebenaran.
- Menyimpan kunci hanya dalam memori, mewujudkan kunci kekal atau pembukaan kunci yang salah selepas ranap berlaku.
- Menerima Timeout pelanggan tanpa had dan bukannya mengembalikan pajakan yang diberikan.
- Hanya membandingkan rentetan token tanpa menyemak skop, penyewa, dan kebenaran prinsipal.
- Membiarkan proksi memainkan semula penulisan yang mempunyai kesan sampingan dan menerapkannya dua kali.
Soalan susulan dan respons
Bilakah anda patut menggunakan 423 berbanding 409?
Gunakan 423 apabila kunci yang berkesan menyekat kaedah tersebut; gunakan 409 apabila tiada kunci wujud tetapi permintaan berkonflik dengan versi atau keadaan semasa. Kedua-duanya memerlukan laluan pemulihan yang boleh didiagnosis.
Bagaimanakah anda mengawal kunci kedalaman infiniti (infinity-depth)?
Hadkan kebenaran dan bilangannya, selesaikan rantaian pewarisan kepada sasaran, dan kira semula liputan untuk operasi alih, salin, dan padam. Tolak secara eksplisit operasi rentas penyewa atau rentas koleksi daripada menganggap adanya pewarisan.
Bolehkah pentadbir memaksa buka kunci (force-unlock) selepas ranap?
Hanya dengan kuasa eksplisit dan sebab audit. Pelanggan biasa menunggu sehingga tamat tempoh; buka kunci secara paksa membatalkan token lama dan merekodkan pengendali, sebab, dan versi sumber.
Bagaimana jika jam pelayan tidak segerak?
Gunakan masa monotonik pada satu nod atau dalam storan berasaskan konsensus untuk tamat tempoh, dan biarkan pelanggan bergantung pada tempoh baki yang diberikan. Pembaharuan rentas nod memerlukan syarat versi supaya dua nod tidak boleh melanjutkan satu kunci secara serentak.