MacOS Webdav not longer working

[QueenGit]

Description If I want to add a new Database via Webdav, it connects to the server, but says Folder empty.

How to reproduce Steps to reproduce the behavior:

1. Go to Connect with Server
2. Tap on WEBdav
3. Enter login data and path to the database file
4. It only shows "Folder empty"

Expected behavior It shows the database file or connect to it automatically if I enter the complete path to the file.

Environment:

• Device: MacBook Air M3
• OS: 14.5
• App Version: 1.52.151

Additional context The database I still have in my list, which is on the same server is working. Also I can't connect to the database if I want to add it in the Autofill dialog.

[keepassium]

Now you only need the server root, not the whole file path: https://keepassium.com/blog/2024/07/keepassium-1.52/#webdav-file-selector

[QueenGit]

I tried the server root, but it don't show me folder or files.

[keepassium]

What do you have as a WebDAV server? (e.g. Nextcloud, Synology…)

[QueenGit]

Its a Webspace from Contabo.com I can connect to the server via Finder, and also the "old" database connection I created a few versions earlier is working.

[keepassium]

Try curl -u username:password -X PROPFIND -H 'Depth: 1' https://serverURL from terminal (with the username, password and serverURL you use in KeePassium).

It should return a long XML with directory contents. Does it? If not, what do you get instead?

[QueenGit]

I get a long XML file with the directory and also if I add /directory to the serverURL I see the .kdbx file

Not sure if it's save to post it here. But if there is any special I should looking for, tell me.

[keepassium]

I get a long XML file with the directory and also if I add /directory to the serverURL I see the .kdbx file

So there is a response, which means KeePassium does not parse it properly… To analyze what goes wrong, it would indeed be useful to take a look at the response.

If you don't feel like posting your file list publicly: create a new directory, copy any couple of files there, and post the response for that directory. Normally the response would not contain anything sensitive, just file names and properties (like this one).

[QueenGit]

<?xml version="1.0" encoding="utf-8"?> <a:multistatus xmlns:b="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/" xmlns:c="xml:" xmlns:a="DAV:" xmlns:Z="urn:schemas-microsoft-com:"><a:response><a:href>/Github_test/</a:href><a:propstat><a:status>HTTP/1.1 200 OK</a:status><a:prop><a:getcontentlength b:dt="int">35</a:getcontentlength><a:creationdate b:dt="dateTime.tz">2024-07-14T14:31:13.000Z</a:creationdate><a:getcontenttype>httpd/unix-directory</a:getcontenttype><a:getlastmodified b:dt="dateTime.rfc1123">Sun, 14 Jul 2024 14:31:13 GMT</a:getlastmodified><a:resourcetype><a:collection/></a:resourcetype><a:supportedlock><a:lockentry><a:lockscope><a:exclusive/></a:lockscope><a:locktype><a:write/></a:locktype></a:lockentry></a:supportedlock><a:ishidden b:dt="boolean">0</a:ishidden><a:iscollection b:dt="boolean">1</a:iscollection></a:prop></a:propstat></a:response><a:response><a:href>/Github_test/database.kdbx</a:href><a:propstat><a:status>HTTP/1.1 200 OK</a:status><a:prop><a:getcontentlength b:dt="int">39422</a:getcontentlength><a:creationdate b:dt="dateTime.tz">2024-07-14T14:31:13.000Z</a:creationdate><a:getcontenttype>httpd/unix-file</a:getcontenttype><a:getlastmodified b:dt="dateTime.rfc1123">Sun, 14 Jul 2024 14:30:57 GMT</a:getlastmodified><a:resourcetype/><a:supportedlock><a:lockentry><a:lockscope><a:exclusive/></a:lockscope><a:locktype><a:write/></a:locktype></a:lockentry></a:supportedlock><a:ishidden b:dt="boolean">0</a:ishidden><a:iscollection b:dt="boolean">0</a:iscollection></a:prop></a:propstat></a:response></a:multistatus>

This is what I get. I created a new folder called 'Github_test' and a new database called 'database.kdbx'

[keepassium]

Thank you for the info, @QueenGit . I suspect the reason is that KeePassium expects XML elements to start with d:, which is how all our test servers responded. But this is not necessarily the case, as the server is free to abbreviate the namespaces as it likes. (For example, in your case it was a:.)

I have added the necessary flexibility to WebDAV response parser, the change will be included in the next beta in a couple of days.

[keepassium]

Hey, the beta with the supposed fix is already published, please give it a try.

[QueenGit]

I tested it, and it's working fine. Thanks for the quick fix.

[keepassium]

Awesome, thanks for confirming!