Permintaan dan ruang lingkup
Layanan berkas kolaboratif mendukung WebDAV dan memungkinkan klien mengedit sumber daya yang sama. Operasi penulisan, pemindahan, atau penghapusan terkadang mengembalikan 423 Locked. Jelaskan batasan antara 423, 409, dan 403; bagaimana klien mendapatkan dan mengirimkan token kunci; cara menangani depth, timeout, pembaruan, dan kegagalan sistem (crash) pemilik; serta cara membuat pemulihan dapat dipantau (observable).
Hal yang diuji oleh pewawancara
- Apakah Anda menjelaskan 423 sebagai kunci yang memblokir sumber daya target, bukan sekadar kesalahan konkurensi generik.
- Apakah Anda memahami Lock-Token, If, Timeout, dan UNLOCK secara terpadu.
- Apakah Anda dapat mendesain sewa (leases), pemulihan koneksi ulang, dan otorisasi tanpa kunci permanen atau pembukaan kunci yang tidak disengaja.
- Apakah klien dapat membedakan antara menunggu, memperoleh kembali (reacquiring), dan kegagalan yang tidak dapat dicoba lagi.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Apakah kunci tersebut merupakan kunci penulisan WebDAV, sewa pengeditan aplikasi, atau keduanya?
- Apakah ini mencakup satu sumber daya atau koleksi dengan kedalaman tak terbatas (infinity-depth), dan bagaimana elemen turunan (children) mewarisi atau menolaknya?
- Di mana token disimpan, dan apakah token tersebut terikat pada penyewa (tenant), prinsipal, versi sumber daya, dan izin?
- Siapa yang memperbarui dan mengambil kembali kunci setelah pemutusan koneksi, crash proses, atau pergeseran waktu (clock skew)?
- Bisakah proksi mencoba kembali operasi penulisan, dan bisakah klien memutar ulang (replay) body permintaan dengan aman?
Jawaban 30 detik
423 menyatakan bahwa sebuah kunci saat ini mencegah penerapan metode pada target; ini bukan penolakan izin generik atau sembarang konflik versi. Saya akan menetapkan cakupan, pemilik, dan sisa masa sewa, lalu mewajibkan Lock-Token yang cocok dalam kondisi If. Layanan memiliki kendali atas sewa dan menggunakan waktu monotonik; pembaruan diotorisasi dan dibatasi, sedangkan masa kedaluwarsa mengambil kembali kunci setelah terjadi crash. Klien memperlakukan 423 sebagai proses menunggu yang terkontrol atau akuisisi ulang, tanpa pernah memutar ulang penulisan non-idempoten secara membabi buta.
Pembahasan mendalam langkah demi langkah
Langkah 1: Tentukan batasan protokol
RFC 4918 menggunakan 423 ketika suatu metode tidak dapat diterapkan pada sumber daya yang terkunci. 403 berkaitan dengan otorisasi dan 409 tentang konflik dengan status saat ini, jadi klasifikasikan penyebab pemblokiran sebelum memilih status.
Langkah 2: Tentukan identitas dan cakupan kunci
Simpan identitas sumber daya, root kunci, kedalaman (depth), pemilik, token, waktu pembuatan, sewa, domain izin, dan versi sumber daya. Kunci dengan infinity-depth dapat mencakup elemen turunan, sehingga server menyelesaikan pewarisan sebelum setiap penulisan daripada hanya memeriksa URL.
Langkah 3: Validasi Lock-Token
Klien memperoleh token dengan metode LOCK dan mengirimkannya dalam kondisi If pada permintaan penulisan, pemindahan, atau penghapusan berikutnya. Server memeriksa token, cakupan, prinsipal, dan penyewa (tenant). Token yang hilang, salah format, atau milik pihak lain akan menerima kegagalan yang dapat didiagnosis tanpa mengekspos pemilik penyewa lain.
Langkah 4: Gunakan sewa untuk batas waktu dan pembaruan
Timeout adalah nilai yang diminta, bukan izin bagi klien untuk membuat sewa tanpa batas. Server menyimpan waktu kedaluwarsa menggunakan jam monotonik, mengotentikasi pembaruan, dan membatasi durasi maksimum. Respons menyatakan batas waktu yang diberikan, dan klien menjadwalkan pembaruan dari nilai tersebut. Kedaluwarsa akan mengambil kembali kunci setelah terjadi crash.
Langkah 5: Tangani pemutusan koneksi dan pemulihan
Setelah terhubung kembali, pemilik menanyakan status kunci dan memperbarui hanya dengan token yang masih valid; cache lokal tidak dapat membuktikan kepemilikan. Proses restart memulihkan sewa dari penyimpanan yang tahan lama (durable storage). Jika pemulihan yang aman tidak dapat dibuktikan, batalkan kunci dan wajibkan akuisisi ulang agar token lama tidak dapat melakukan penulisan.
Langkah 6: Pisahkan proses menunggu dari mencoba kembali
Klien dapat menampilkan status agnostik-pemegang seperti "sumber daya sedang diedit" dan melakukan polling dengan backoff berdasarkan sisa masa sewa. 423 bukanlah kegagalan jaringan sementara. Coba kembali penulisan hanya jika token, versi, dan body dikonfirmasi dapat diputar ulang; proksi tidak boleh memutar ulang permintaan non-idempoten yang hasil eksekusinya tidak diketahui.
Langkah 7: Amati dan batasi penyalahgunaan
Catat hash sumber daya, cakupan kunci, sisa sewa, alasan kegagalan, hash prinsipal, dan ID permintaan. Ukur tingkat 423, durasi penahanan, kegagalan pembaruan, reklamasi kedaluwarsa, dan jumlah depth-lock berdasarkan tenant, jenis sumber daya, dan versi klien. Batasi jumlah depth-lock, sewa maksimum, dan percobaan token untuk mencegah habisnya sumber daya dan tebakan token.
Contoh jawaban berkualitas tinggi
Pertama-tama, saya akan membuktikan bahwa 423 adalah kunci WebDAV, memisahkannya dari otorisasi 403 dan konflik status aplikasi 409. Layanan kunci menyimpan sumber daya, kedalaman, prinsipal, tenant, Lock-Token, sewa yang diberikan, dan versi secara tahan lama. Klien memperoleh token dengan LOCK dan mengirimkannya di If; server memvalidasi token, cakupan, prinsipal, dan izin secara bersamaan. Sewa menggunakan waktu monotonik sisi server dan durasi maksimum. Setelah terputus, klien hanya dapat memperbarui dengan token yang valid; setelah crash, kedaluwarsa akan mereklamasi kunci tersebut. Klien menyajikan status "sedang diedit" yang dapat dipulihkan, melakukan polling dengan backoff, dan tidak pernah mencoba kembali penulisan dengan hasil yang tidak pasti secara membabi buta. Telemetri produksi mencakup rasio 423, durasi penahanan, kegagalan pembaruan, reklamasi, dan jumlah depth-lock, dilengkapi pengujian untuk klien yang saling bersaing, restart, pergeseran waktu, dan percobaan ulang proksi.
Kesalahan umum
- Mengembalikan 423 untuk setiap konflik konkurensi dan menyembunyikan kesalahan versi atau izin.
- Menyimpan kunci hanya di memori, yang menyebabkan kunci permanen atau pembukaan kunci yang salah setelah crash.
- Menerima Timeout klien yang tidak terbatas alih-alih mengembalikan sewa yang diberikan.
- Hanya membandingkan string token tanpa memeriksa cakupan, tenant, dan izin prinsipal.
- Membiarkan proksi memutar ulang operasi penulisan yang memiliki efek samping sehingga diterapkan dua kali.
Pertanyaan lanjutan dan tanggapan
Kapan Anda harus menggunakan 423 versus 409?
Gunakan 423 jika kunci yang aktif memblokir metode tersebut; gunakan 409 jika tidak ada kunci tetapi permintaan berkonflik dengan versi atau status saat ini. Keduanya memerlukan jalur pemulihan yang dapat didiagnosis.
Bagaimana cara membatasi kunci dengan kedalaman tak terbatas (infinity-depth)?
Batasi izin dan jumlahnya, selesaikan rantai pewarisan ke target, dan hitung ulang cakupan untuk pemindahan, penyalinan, dan penghapusan. Tolak secara eksplisit operasi lintas-penyewa atau lintas-koleksi daripada mengasumsikan pewarisan.
Bisakah administrator membuka kunci secara paksa setelah terjadi crash?
Hanya dengan wewenang eksplisit dan alasan audit yang jelas. Klien biasa menunggu hingga kedaluwarsa; pembukaan paksa membatalkan token lama dan mencatat operator, alasan, serta versi sumber daya.
Bagaimana jika jam server tidak sinkron?
Gunakan waktu monotonik pada satu node atau dalam penyimpanan yang didukung konsensus untuk kedaluwarsa, dan biarkan klien bergantung pada durasi sisa yang diberikan. Pembaruan lintas-node memerlukan kondisi versi sehingga dua node tidak dapat memperpanjang satu kunci secara bersamaan.