Environment
rmfakecloud: v0.0.31 on Dockerhub
WebDAV backend: Managed Nextcloud (ionos), endpoint remote.php/dav/files//, authenticated with app password
Device: reMarkable2
Behavior
When browsing a WebDAV integration folder, the request fails silently with a 503 error.
rmfakecloud logs show:
level=info msg="[GIN] ... | 500 | ... | GET "/integrations/v2/storage//folders/root?folderDepth=2""
level=info msg="[webdav] query for: / depth: 2"
level=error msg="PROPFIND /: 503"
Root cause
rmfakecloud appears to pass the folderDepth query parameter directly through as the HTTP Depth header on the outgoing PROPFIND request to the WebDAV backend. Per RFC 4918, the only valid values for the Depth header are 0, 1, or infinity. Depth: 2 is not a valid WebDAV value.
Nextcloud's ValidateRequestPlugin (part of nextcloud/server, in the dav app) rejects requests with invalid/unexpected headers by throwing a \Sabre\DAV\Exception\ServiceUnavailable, which maps to HTTP 503. This explains why the request fails specifically with 503 rather than a more typical 400.
Reproduction / proof
Manually issuing the same PROPFIND request with a valid Depth: 1 header against the exact same endpoint, from within the same Docker network namespace as the rmfakecloud container, succeeds without issue:
curl -v -u ':' -X PROPFIND -H "Depth: 1"
https:///remote.php/dav/files//
< HTTP/2 207
This confirms the backend, credentials, TLS, and network path are all fine — the only difference between the failing rmfakecloud request and the succeeding manual request is the Depth header value (2 vs 1).
Suggested fix
Either:
Cap the outgoing Depth header at 1 and have rmfakecloud recurse into subfolders with additional requests when a deeper folderDepth is requested, or
Map folderDepth > 1 to Depth: infinity (many WebDAV servers, including Nextcloud, support this for a single recursive listing), with a fallback to manual recursion if infinity is rejected.
Environment
rmfakecloud: v0.0.31 on Dockerhub
WebDAV backend: Managed Nextcloud (ionos), endpoint remote.php/dav/files//, authenticated with app password
Device: reMarkable2
Behavior
When browsing a WebDAV integration folder, the request fails silently with a 503 error.
rmfakecloud logs show:
level=info msg="[GIN] ... | 500 | ... | GET "/integrations/v2/storage//folders/root?folderDepth=2""
level=info msg="[webdav] query for: / depth: 2"
level=error msg="PROPFIND /: 503"
Root cause
rmfakecloud appears to pass the folderDepth query parameter directly through as the HTTP Depth header on the outgoing PROPFIND request to the WebDAV backend. Per RFC 4918, the only valid values for the Depth header are 0, 1, or infinity. Depth: 2 is not a valid WebDAV value.
Nextcloud's ValidateRequestPlugin (part of nextcloud/server, in the dav app) rejects requests with invalid/unexpected headers by throwing a \Sabre\DAV\Exception\ServiceUnavailable, which maps to HTTP 503. This explains why the request fails specifically with 503 rather than a more typical 400.
Reproduction / proof
Manually issuing the same PROPFIND request with a valid Depth: 1 header against the exact same endpoint, from within the same Docker network namespace as the rmfakecloud container, succeeds without issue:
curl -v -u ':' -X PROPFIND -H "Depth: 1"
https:///remote.php/dav/files//
< HTTP/2 207
This confirms the backend, credentials, TLS, and network path are all fine — the only difference between the failing rmfakecloud request and the succeeding manual request is the Depth header value (2 vs 1).
Suggested fix
Either:
Cap the outgoing Depth header at 1 and have rmfakecloud recurse into subfolders with additional requests when a deeper folderDepth is requested, or
Map folderDepth > 1 to Depth: infinity (many WebDAV servers, including Nextcloud, support this for a single recursive listing), with a fallback to manual recursion if infinity is rejected.