WebDAV PUT runs through the same chunked pipeline as the native upload. Large files do not sag, sync clients work, rclone works, phone auto-sync works. The protocol is a first-class path, not a slow fallback.
Cotton exposes WebDAV v1 for standard clients and automation workflows. It is useful when you need protocol-level access instead of only the browser UI.
WebDAV PUT streams into Cotton's chunk storage path. That means uploaded files still become content-addressed, encrypted, previewable, shareable, restorable Cotton files.
PROPFIND responses include quota-used-bytes and, when a user has a quota, quota-available-bytes. Clients that understand those properties can report real logical quota instead of guessing from the backing disk.
Use WebDAV for compatibility, automation, basic sync, and existing client workflows. Use the web UI for richer product flows such as previews, shares, profile security, sessions, notifications, and admin checks.
WebDAV is not the long-term center of gravity for Cotton. It is a bridge for broad client compatibility while the product keeps its own chunk-first storage model underneath.
The important proof is that WebDAV writes do not bypass the product engine. They enter the same storage path as browser uploads, so compatibility clients still create Cotton-managed files with manifests, chunks, encryption, quota accounting, and metadata.
Cotton can be practical on day one because existing WebDAV clients already exist. That compatibility matters, but it stays subordinate to the product's native file cloud model.
WebDAV is a compatibility layer, not the richest Cotton experience. Use it for sync and automation; use the web UI for previews, sharing, account security, sessions, notifications, and admin checks.
Cotton treats WebDAV as a practical bridge: standard clients can get file access today, while the native product keeps the richer file cloud model around previews, shares, snapshots, security, and admin visibility.
WebDAV v1 exists for standard clients, phone auto-sync, rclone-style workflows, and automation that needs protocol access.
WebDAV PUT streams into the chunk storage path instead of becoming a separate whole-file backend beside the product.
PROPFIND can expose quota-used-bytes and quota-available-bytes, so clients see Cotton account limits instead of raw disk guesses.
WebDAV token reset and failed token attempts are part of the same account and notification posture as the web app.
Use the protocol where standards matter and use the Cotton UI where the product has more context. Both paths land in the same storage model, which keeps previews, sharing, restore, and integrity behavior coherent.
Cotton can meet users where their tools already are: WebDAV for broad compatibility, and the browser UI for the product features that make the file cloud worth running.
WebDAV client behavior varies, and the protocol is not Cotton native sync. It is the compatibility path, not the long-term center of gravity.
Yes. WebDAV uploads enter the normal Cotton storage path, so they become chunked, encrypted, and represented through manifests like browser uploads.
Choose Cotton if you want a self-hosted file cloud where WebDAV is one compatibility surface beside the UI, previews, sharing, snapshots, passkeys, and admin safety checks.
No. WebDAV is for compatibility, sync clients, and automation. The web UI is where previews, share context, account security, notifications, and admin diagnostics are richer.