DAV:displayname

[alex-eri]

I think that displayname must not urlencoded because it is not url.

Bad file names on Nautilus:

<D:response>
<D:href>/dav/%D0%92%D0%B5%D0%BB%D0%B8%D0%B6%D1%81%D0%BA%D0%B0%D1%8F%201</D:href>
<D:propstat>
<D:prop>
<D:creationdate>2019-07-09T17:20:44Z</D:creationdate>
<D:displayname>%D0%92%D0%B5%D0%BB%D0%B8%D0%B6%D1%81%D0%BA%D0%B0%D1%8F%201</D:displayname>
<D:getcontentlanguage/>
<D:getcontentlength>4096</D:getcontentlength>
<D:getcontenttype/>
<D:getetag/>
<D:getlastmodified>Tue, 09 Jul 2019 17:20:44 GMT</D:getlastmodified>
<D:lockdiscovery/>
<D:resourcetype><D:collection/></D:resourcetype>
<D:source/>
<D:supportedlock/>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>

15.2. displayname Property

Name: displayname

Purpose: Provides a name for the resource that is suitable for
presentation to a user.

Value: Any text.

Protected: SHOULD NOT be protected. Note that servers implementing
[RFC2518] might have made this a protected property as this is a
new requirement.

COPY/MOVE behavior: This property value SHOULD be preserved in COPY
and MOVE operations.

Description: Contains a description of the resource that is
suitable for presentation to a user. This property is defined on
the resource, and hence SHOULD have the same value independent of
the Request-URI used to retrieve it (thus, computing this property
based on the Request-URI is deprecated). While generic clients
might display the property value to end users, client UI designers
must understand that the method for identifying resources is still
the URL. Changes to DAV:displayname do not issue moves or copies
to the server, but simply change a piece of meta-data on the
individual resource. Two resources can have the same DAV:
displayname value even within the same collection.

[alex-eri]

Or not to use D:displayname as Apache do

<D:response xmlns:lp1="DAV:" xmlns:lp2="http://apache.org/dav/props/" xmlns:g0="DAV:">
<D:href>/dav/%d0%92%d0%b5%d0%bb%d0%b8%d0%b6%d1%81%d0%ba%d0%b0%d1%8f%201/</D:href>
<D:propstat>
<D:prop>
<lp1:creationdate>2019-07-09T17:20:44Z</lp1:creationdate>
<D:getcontenttype>httpd/unix-directory</D:getcontenttype>
<lp1:getetag>"1000-58d42c7e6ec99"</lp1:getetag>
<lp1:getlastmodified>Tue, 09 Jul 2019 17:20:44 GMT</lp1:getlastmodified>
<lp1:resourcetype><D:collection/></lp1:resourcetype>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop>
<g0:displayname/>
<g0:getcontentlength/>
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:response>

[stokito]

Probably this is already fixed.
The problem is here
https://github.com/arut/nginx-dav-ext-module/blob/master/ngx_http_dav_ext_module.c#L1745

ngx_escape_html(dst, entry->name.data, entry->name.len);

And the function's source looks clear http://agentzh.org/misc/code/nginx/core/ngx_string.c.html#L1709

Maybe nginx maintainers should update the plugin in distros.

FYI: the issue is reported 4 years ago in the Nginx tracker https://trac.nginx.org/nginx/ticket/970