Skip to content

Latest commit

 

History

History
108 lines (72 loc) · 3.51 KB

TODO.md

File metadata and controls

108 lines (72 loc) · 3.51 KB
Raw

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.