WebDAV PROPFIND <D:href> is not percent-encoded for FileNode objects created via JMAP, breaking WebDAV clients (spec violation of RFC 3986)

Issues
1

Issue Description

When a file/folder (FileNode) is created through the JMAP API (FileNode/set), the resulting object’s <D:href> in subsequent WebDAV PROPFIND responses contains the raw, unencoded name (including literal spaces and raw UTF-8 bytes for non-ASCII characters) instead of a properly percent-encoded path segment.

Objects created directly via WebDAV (MKCOL/PUT) are, by contrast, always correctly percent-encoded in their href.

This produces a PROPFIND response containing an invalid URI (per RFC 3986, spaces and non-ASCII bytes in a URI path must be percent-encoded), which appears to cause spec-compliant WebDAV clients to silently fail to display or access the affected resource.

Stalwart Version

v0.16.x

Installation Method

Docker

Database Backend

RocksDB

Blob Storage

RocksDB

Search Engine

Internal

Directory Backend

Internal

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

Please see this full MD file

2

Fixed in v0.16.19 (yet to be released).

3

Thanks for the reply, any idea on the next release date?

4

Today, it is being compiled.

5

thanks but I still see the same problem I did update to v.0.16.19

image
image688×604 4.41 KB

6

just to be on the same page
xxxx@mail:~# cd /opt/stalwart
cp -r etc etc.bak-$(date +%Y%m%d_%H%M)
docker compose pull
docker compose up -d
sleep 5
docker exec stalwart /usr/local/bin/stalwart --version
[+] pull 7/7
:check_mark: Image stalwartlabs/stalwart:v0.16 Pulled 3.6s
[+] up 1/1
:check_mark: Container stalwart Started 2.7s
0.16.19

these are the commands used to uddate. but same problem show up on file or folder name

7

Based on your screenshot, Stalwart is properly percent encoding the JMAP resources but your client is not decoding them. Have you tried deleting the DAV mount and adding it again? If so please send the raw PROPFIND response.

8

the client is bulwark web based via firefox could it be the source of the display bug?

9

It depends. If the screenshot is Bulwark and those files were created via WebDAV, then it is a Stalwart bug (but not the same bug you originally reported). If the screenshot comes from your WebDAV client and the files were created using Bulwark then it’s likely a WebDAV client bugs but we need logs to confirm.

10

I went on and tested Winscp → showing all file names correct using the webdav client.
Also RaiDrive shows file names correct, so could it be the bulwark bug?

11

can you give me the exact logs you want to see so I can generate?