WebDAV

The file body still moves with GET and PUT. The extra methods are what make a remote folder feel like a drive.

A plain PUT stores one object. WebDAV adds PROPFIND to list a collection, MKCOL to create a folder, MOVE and COPY for namespace changes, and LOCK so two editors do not overwrite each other. Clients such as operating-system file mounts and sync agents speak these methods against an HTTPS endpoint. The user sees folders. The wire is HTTP.

A design team mounts `https://files.example/jobs/441/` as a drive. Opening the folder sends PROPFIND. Saving `cover.psd` sends PUT. A second user opens the same file and takes a LOCK. The first user's later PUT returns a locked conflict instead of a silent overwrite. Without the lock, last writer wins and Monday's edits disappear. That collision avoidance is the reason RFC 4918 exists. A transfer link that only allows GET never sends PROPFIND or LOCK. It is a download, not a WebDAV share.

WebDAV is not FTP and not SFTP. It inherits HTTP's single connection, proxies, and TLS. It also inherits HTTP's oddities: some proxies strip methods they do not know, and a LOCK left by a crashed client blocks writes until the timeout. Depth and property XML make listings heavier than an SFTP directory read. Servers that advertise WebDAV and implement only GET and PUT will mount, then fail on rename.

Do not treat "WebDAV" as a security claim. The spec is about authoring. Encryption is whatever TLS the HTTPS host uses. Permissions are the server's access rules on each URL. A world-readable collection is a public folder that happens to speak PROPFIND.