You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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 appendeddefault'';
}
server {
# ...# HACK: internal redirect for webdav clients that don't append slashif ($filestash_fixdav = 2) {
rewrite(.*) $1/ last;
}
# ...
}
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.
The text was updated successfully, but these errors were encountered:
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:
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:
This appears to be the same bug as #578.
Step by step instructions to reproduce the bug
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.
The text was updated successfully, but these errors were encountered: