Lighttpd

DAV:displayname property is optional, and is supported in lighttpd mod_webdav. As commented in the code, if "displayname" property is set (by a client), then "displayname" will be returned when the client (or a different client) queries properties with PROPFIND.

recently I came across a client that needs the displayname Property

but you failed to share a very simple piece of information: the client. Your client is poorly written if it is unable to properly handle an optional property which is not present.

BTW, https://sabre.io/dav/clients/windows/ notes that Windows XP was broken with displayname and suggests omitting the property, at least for Windows XP.

NextCloud discussed and appears to have added displayName as a protected property
https://github.com/nextcloud/server/issues/17778
https://github.com/nextcloud/server/pull/34508
even though RFC 4918 http://www.webdav.org/specs/rfc4918.html#PROPERTY_displayname states that the property "SHOULD NOT be protected."

If displayName is always going to be basename of the URL path, then why bother duplicating it as a separate property?

Absent valid use cases for displayName, there is merit to protecting the displayName property to avoid potential security issues in misuse/abuse of displayName to trick other clients.

Thanks for the quick reply! With your answer I was able to read a bit more about properties. So if I understand you correctly it is in fact up to the client to set such property, then it will be stored by lighttpd in its db set by webdav.sqlite-db-name, and then the client can retrieve it later when needed. If the client has not set it ever, there are no displayname properties to be retrieved even when asked specifically.

For instannce:

curl -u username -X PROPFIND -H Depth:1 -H 'Content-Type: application/xml' http://some.where/nice/ -d '<D:propfind xmlns:D="DAV:"><D:prop><D:displayname/></D:prop></D:propfind>'

returns <D:status>HTTP/1.1 404 Not Found</D:status>

Is this correct?

The client is https://github.com/J-D-K/JKSV which recently added experimental WebDAV support.

So there is a client (JKSV) which recently added experimental WebDAV support and you posted assuming that lighttpd was doing something incorrectly or insufficiently, rather than first looking if your new hotness might be the thing that needs tweaking? ...and you failed to share the name of this experimental client in your original post, and that it was experimental. None of this is a good way to show that you value someone else's time.

So if I understand you correctly it is in fact up to the client to set such property, then it will be stored by lighttpd in its db set by webdav.sqlite-db-name, and then the client can retrieve it later when needed. If the client has not set it ever, there are no displayname properties to be retrieved even when asked specifically.

Yes.

lighttpd is operating as designed unless you can demonstrate otherwise.
lighttpd mod_webdav is tested with with litmus client (mod_webdav litmus tests)

From some quick searches in a search engine. YMMV.

A post from 2013:
https://stackoverflow.com/questions/14599703/may-the-path-be-unrelated-to-the-name-of-a-file-in-webdav#14601222

I know that for webdav generally there is a display-name property which is independent of the resource href.

BUT this property IS NOT USED by most webdav clients. Instead webdav clients generally just use the last path segment as the file name and ignore the displayname property.

Undated, but well over a decade old description of limitations of displayName.
https://flylib.com/books/en/2.320.1.63/1/

7.5.2 displayname

The display name of a resource is the string that should be shown to the user. Often, it's a different string than the file name. Many systems restrict file names to limited sets of characters, but display names for resources ought to be able to handle international character sets. When WebDAV was defined, there were few reasonable options for displaying non-ASCII characters in URLs, so displayname was defined in part for better internationalization characteristics.

Some examples of valid displayname property values:

Many WebDAV servers (Exchange 2000, IIS 5.0, Xythos WFS 4.0) tie the value of displayname to the URL so that if the final element in the URL path is readme.htm, the value of displayname must also be readme.htm. This doesn't contravene any normative statements in the WebDAV RFC, but it doesn't match what the WebDAV designers had in mind. It means the displayname value must be unique within a collection, and it can't change without making links break. On these implementations, the displayname property is protected so that clients cannot change the value directly. If a resource is renamed with a MOVE request, the value of displayname automatically changes.

Exchange 2000 defines another way to assign friendly, non-unique names to files. The user may change the value of a subject property, which is initially given the same value as displayname but may be changed. The subject value does not have to be unique within a collection, so a user may see many emails in an Exchange 2000 folder with the same subject but different URLs and displayname values.

The mod_dav implementation treats displayname almost as if it were a dead property. When a new resource is created on a mod_dav server, displayname is left blank. It is writable, so the user can give it a value later. The disadvantage to this approach is that the property will be left blank most of the time, so it ends up being ignored by clients.

The different implementations seem to have left the displayname property at an impasse, unusable. Since clients can't rely on the property being writable, clients don't use it as a display name. The working group could update the standard to declare it to be a writable property, but this would make some deployed clients and servers uninteroperable or noncompliant. Some discussions have involved defining a new property that is clearly required to be writable, but the question is still wide open.

Thanks for the explanations!
Have a lovely rest of the day.
Greetings.