WebDAV entry: item names lose their first character when Home directory is “/” (hrefs not resolved against the request URL)

WebDAV entry: item names lose their first character when Home directory is “/” (hrefs not resolved against the request URL)

avatar

RDM 2026.3.16.0 (Windows), WebDAV session entry against a small embedded WebDAV server (Pi1MHz firmware, HTTP, no authentication).

The Home directory field is mandatory, so for the server’s root I set it to /. RDM then sends PROPFIND // HTTP/1.1 (Depth 1, User-Agent DevolutionsWebdavClient, allprop body; captured with a logging relay in between). The server answers 207 Multi-Status with valid absolute-path hrefs; the display names are the full names:

<D:href>/</D:href>        <D:displayname>/</D:displayname>
<D:href>/Backup/</D:href> <D:displayname>Backup</D:displayname>
<D:href>/tdisc/</D:href>  <D:displayname>tdisc</D:displayname>

RDM lists every item with its first character missing: ackup, disc, emos ... (all 27 folders and files). It looks as if RDM removes the length of its own request path (2 characters, //) from each href, instead of resolving the href against the request URL (RFC 4918 lets the server use any href form for the resource; RFC 3986 section 5 for the resolution) or using displayname.

Controls: Windows Explorer (WebClient) lists the same server correctly. With curl, PROPFIND on / and on // return identical hrefs, so the server is consistent; only the request path differs. An independent server, rclone 1.75.2 (rclone serve webdav), answers // the same way: 207 with the same /-prefixed hrefs as for /. RDM shows the same shortened names against that server too.

Could you please (1) resolve each href against the request URL (or use displayname) when building the list, and (2) accept / as the home directory without producing // in the request? An empty home directory would also do, but the field cannot be left empty.

kind regards

Mark

All Comments (0)