# 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](https://tools.ietf.org/html/rfc4437) -- basically support for symbolic links

- implement [RFC3744 Webdac ACL](https://tools.ietf.org/html/rfc3744)

## 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.