[bug] WebDAV does not resolve directories without trailing slash

[sevmonster]

Description of the bug

Unless this is intentional WebDAV behavior, I've noticed that attempting to navigate directories without a trailing slash in the URI will not work. Adding a slash fixes this, but it is not always possible to do this, i.e. if the client is navigating to subdirectories for you and trying to fetch its children. In that case, the directory will simply appear to be empty.

Digging a bit deeper I see this in the logs:

filestash       | 2024/02/13 05:32:34 HTTP   0 OPTIONS  129.3ms /s/someshare
filestash       | 2024/02/13 05:32:34 HTTP 404 PROPFIND  108.8ms /s/someshare
filestash       | 2024/02/13 05:32:34 HTTP 404 PROPFIND  106.9ms /s/someshare

I am also able to replicate this with cURL:

$ curl -iX OPTIONS https://files.my.site/s/someshare
HTTP/2 200 
server: nginx
date: Tue, 13 Feb 2024 05:49:57 GMT
content-length: 0
allow: OPTIONS, LOCK, PUT, MKCOL
dav: 1, 2
ms-author-via: DAV
[...]

$ curl -X PROPFIND https://files.my.site/s/someshare -H "Depth: 1"
HTTP/2 404
[...]

Not Found

This isn't a Nginx or HTTP/2 issue, as the same problem occurs with requests to the local port directly to the service.

Looking at the library code, that set of methods for the Allow header seems to only be returned if the file doesn't exist, and a 404 is returned for the same reason. So I guess the library is having trouble finding the files from the backend.

Testing a share link on the Filestash demo site with WebDAV works fine, as Filestash does add the slash, but I encounter issues with other clients. I have tested Windows Explorer's Add network location and KDE Dolphin's webdavs:// scheme and both suffer from this problem.

This can easily be worked around with a rewrite in a reverse proxy. I used the following Nginx config to kludge it:

map $request_uri#$request_method#$http_user_agent $filestash_fixdav {
    # ...
    ~^/s/.+[^/]#PROPFIND# 2; # make sure dir lookups have slash appended
    default '';
}

server {
    # ...

    # HACK: internal redirect for webdav clients that don't append slash
    if ($filestash_fixdav = 2) {
        rewrite (.*) $1/ last;
    }

    # ...
}

This appears to be the same bug as #578.

Step by step instructions to reproduce the bug

1. Create a share link
2. Attempt to add it to Windows Explorer via the Add network location feature or KDE Dolphin's webdavs:// URI scheme.

Can you replicate that error from the demo?

Yes, from a fresh share link:

$ curl -iX OPTIONS https://demo.filestash.app/s/U3oa1Dl
HTTP/1.1 200 OK
Server: nginx/1.25.1
Date: Tue, 13 Feb 2024 05:58:00 GMT
Content-Length: 0
Connection: keep-alive
Allow: OPTIONS, LOCK, PUT, MKCOL
Dav: 1, 2
Ms-Author-Via: DAV

$ curl -iX PROPFIND https://demo.filestash.app/s/U3oa1Dl
HTTP/1.1 404 Not Found
Server: nginx/1.25.1
Date: Tue, 13 Feb 2024 05:57:45 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 9
Connection: keep-alive

Not Found

This shows that it isn't just my chosen backend (local folder), but it also happens with S3.

Observed behavior

Directories are not navigable.

With Dolphin, it does respect appending a slash manually to the URI, so doing so fixes it for the toplevel directory and allows you to see the first level of children. However, you cannot navigate any deeper.

With Explorer, the slash is unilaterally stripped from all URIs, so it will never work without kludging the URI in the proxy.

Expected behavior

Directories are navigable under both KDE Dolphin and Windows Explorer.