Windows Explorer WebDAV interop (last client from the v0.1 matrix) #2
Labels
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Cordy/Cairn#2
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
WebDAV is verified against curl only (all methods return correct status codes and payloads). Real clients are pickier — each has quirks around LOCK, PROPFIND properties, trailing slashes, and header casing.
Test matrix (v0.1 gate):
rclone lsd/copy/syncagainst/dav/(most important: it's the power-user path and the easiest to automate in CI later)OPTIONSon/and Basic-over-HTTP registry caveat documented)Document per-client findings + required workarounds in the wiki. Anything requiring protocol changes gets its own issue.
Client interop matrix complete against v0.0.2 (2026-07-20):
._*traffic. Pod 0 restarts (this was the #5 killer traffic).interop-rclone.ymlmanual-dispatch workflow on the LAN runner: lsd, upload,rclone check(0 differences; no common hash — expected, WebDAV exposes none), round-trip download byte-identical, purge cleanup. Re-runnable any time from the Actions tab (needsCAIRN_TEST_PASSWORDsecret, already set).cyberduck-test), upload (5.9 KB), download round-trip (size-verified), DELETE cleanup. Only client-side notes: Cyberduck's plaintext-HTTP warning (expected on LAN; goes away if/whenfiles.c0rdyceps.chTLS exposure happens) and its 401→login-prompt flow on first connect (normal Basic-auth challenge handling).Pod stayed Running, 0 restarts across all three clients. Windows Explorer remains untested (no Windows box handy) — leaving as a nice-to-have.
Status (2026-07-25): rclone, Finder, Cyberduck all verified against the live dogfood (2026-07-20). Windows Explorer is the only remaining client — moved to v0.4 as the parity item. Nextcloud desktop client is superseded by the dedicated "Desktop sync client — strategic spike" (#20).
Triage: tandem (manual client testing). WebDAV interop across rclone, Finder, Cyberduck, Windows Explorer on real OSes — mount, up/download, rename, large files, the NFC path fix (#183). I can supply a test matrix/checklist; you run the clients and report. Some paths are already covered by the CI interop workflows (rclone/tus).
v0.1: WebDAV client interop testing (rclone, Finder, Cyberduck, Explorer)to Windows Explorer WebDAV interop (last client from the v0.1 matrix)Retitled (2026-09-03): rclone, Finder and Cyberduck were all verified 2026-07-20 and the Nextcloud client is superseded by #20 — Windows Explorer is the only remaining client, so the issue now says exactly that.
One thing has changed since the last triage that makes this test more valuable, not less: per-file locks (#315) replaced the old granted-and-ignored WebDAV LOCK tokens with real, enforced class-2 locking. Explorer/Office on Windows is the strictest lock client in the matrix, so the Explorer pass should now also cover: open a Word/Excel file from the mapped drive (lock appears on the admin Locks page and in the row chip), attempt a conflicting edit from a second account (should be refused with 423), close the document (lock released), plus the classic Explorer checks — map drive, browse, up/download, rename, large file, umlaut/NFC filenames (#183). Tandem as before: checklist from the agent, clients run by the operator.