webdav-handler-rs/TODO.md

TODO list

Protocol compliance

Apply all headers

The RFC says that for COPY/MOVE/DELETE with Depth: Infinity all headers must be applied to all resources. For example, in RFC4918 9.6.1:

Any headers included with DELETE MUST be applied in processing every resource to be deleted.

Currently we do not do this- we do apply the If-Match, If-None-Match, If-Modified-Since, If-Unmodified-Since, and If headers to the request url, but not recursively.

Props on symbolic links

Should probably disallow that

In MOVE/DELETE test locks seperately per resource

Right now we check if we hold the locks (if any) for the request url, and paths below it for Depth: Infinity requests. If we don't, the entire request fails. We should really check that for every resource to be MOVEd/DELETEd seperately and only fail those resources.

This does mean that we cannot MOVE a collection by doing a simple rename, we must do it resource-per-resource, like COPY.

Race conditions

During long-running requests like MOVE/COPY/DELETE we should really LOCK the resource so that no other request can race us.

Actually, check if this is true. Isn't the webdav client responsible for this?

Anyway:

• if the resource is locked exclusively and we hold the lock- great, nothing to do
• otherwise:
• lock the request URL exclusively (unless already locked exclusively), Depth: infinite, without checking if any other locks already exist. This is a temporary lock.
• now check if we actually can lock the request URL and paths below
• if not, unlock, error
• go ahead and do the work
• unlock

The temporary lock should probably have a timeout of say 10 seconds, where we refresh it every 5 seconds or so, so that a stale lock doesn't hang around too long if something goes catastrophically wrong. Might only happen when the lock database is seperate from the webdav server.

Improvements:

• Do fake locking only for user-agents:

  • /WebDAVFS/ // Apple
  • /Microsoft Office OneNote 2013/' // MS
  • /^Microsoft-WebDAV/ // MS

  this is the list that NextCloud uses for fake locking. probably (WebDAVFS|Microsoft) would do the trick.

• API: perhaps move filesystem interface to Path/PathBuf or similar and hide WebPath

• add documentation

• add tests, tests ...

Project ideas:

• Add support for properties to localfs.rs on XFS. XFS has unlimited and scalable extended attributes. ext2/3/4 can store max 4KB. On XFS we can then also store creationdate in an attribute.

• Add support for changing live props like mtime/atime

  • atime could be done with Win32LastAccessTime
  • allow setting apache "executable" prop
  • it appears that there are webdav implementations that allow you to set "DAV:getcontentlength".

• we could support (at least return) some Win32FileAttributes:

  • readonly: 00000001 (unix mode)
  • hidden: 00000002 (if file starts with a "."
  • dir: 00000010
  • file: 00000020

  readonly on dirs means "all files in the directory" so that is best not implemented.

• allow setting of some windows live props:

  • readonly (on files, via chmod)
  • Win32LastAccessTime, Win32LastModifiedTime

• implement RFC4437 Webdav Redirectref -- basically support for symbolic links

• implement RFC3744 Webdac ACL

Things I thought of but aren't going to work:

Compression

• support for compressing responses, at least PROPFIND.
• support for compressed PUT requests

Nice, but no webdav client that I know of uses compression.