WebDAV - use file/folder name for dav:displayname

[starypatyk]

Fix #17778

Follow-up to #34471 - also found during investigation of nextcloud/android#10783.

I have found that:

• The Android client requests dav:displayname property when reading folder contents.
• The FilesPlugin does not handle this property.
• Handling falls back to CustomPropertiesBackend and executes a database query for each file in the folder.

This is an attempt to improve performance by handling the dav:displayname property in the FilesPlugin and avoiding the fallback.

Performance results - 331 files in a folder, assuming #34471 is in place, timings are not very consistent:

_	Execution time [ms]	# of DB queries
Before	365	372
After	270	41

Additional notes:

• This changes responses of WebDAV PROPFIND calls for files/folders. The dav:displayname used to be returned in 404 Not Found section of the multistatus response, now the file/folder name is returned in 200 OK section. I am not sure if this can break some clients. On the other hand there has been a request to return displayname in some cases. After reading RFC4918, I am not 100% sure that the new behaviour is fully compliant, but seems to be close. 😉
• As discussed with @PVince81, trying to PROPPATCH this property will mow raise an error (403). Seems to be more or less in line with the RFC.
• When sharing a folder with a public link, the folder name is already visible in the UI to the anonymous user, so it seems that with this change we do not disclose more information that previously.
• The documentation should be updated to reflect the change.

[tobiasKaminsky]

Let us check our clients:

• Android: we have code for it, with fallback to use path
• iOS: do you request it? @marinofaggiana
• Desktop: do you request it? @nextcloud/desktop

[PVince81]

For the background: before this PR it would be possible for a user to manually send a PROPPATCH to set an arbitrary value for "dav:displayname". If the clients were using it, it would then affect how the file name is displayed there. That property is not used in the web UI, so the behavior would be inconsistent anyway.

I just wonder if there was a past use case that existed for that property ?

[PVince81]

👍 as discussed

[marinofaggiana]

For the background: before this PR it would be possible for a user to manually send a PROPPATCH to set an arbitrary value for "dav:displayname". If the clients were using it, it would then affect how the file name is displayed there. That property is not used in the web UI, so the behavior would be inconsistent anyway.

I just wonder if there was a past use case that existed for that property ?

iOS use it but ... if not more present is not a problem, I can replace it ... please ping me if we want remove it

[tobiasKaminsky]

I just wonder if there was a past use case that existed for that property ?

@starypatyk and me was thinking about card dav / cal dav, where a display name is different from actual "file" representation.
But for files/folders we failed to find a use case why display name needs to be different from actual file on file system.
(maybe for such things like Trashbin on Windows, which are internally always trashbin, but are translated to language of user, but this is not something we do)

--> if display-name works and shows 1:1 as last part of href, it is fine :)

[mgallien]

desktop client is not using dav:displayname
on windows translations of folder name are done directly in the files explorer UI
as soon as you go command line, you will see non localized names (for the few folder names that are localized)

[starypatyk]

I did very brief checks of some clients with the proposed changes applied.

• Windows 10 (built-in WebDAV Redirector) - does not request the dav:displayname attribute
• Kodi (previously XBMC) 19.4 - does not request the dav:displayname attribute
• GNOME gvfs/1.44.1 (Ubuntu 20.04) - requests the dav:displayname attribute - I have not observed any issues
• GNOME gvfs/1.48.2 (Ubuntu 22.04) - same as above

[PVince81]

on windows translations of folder name are done directly in the files explorer UI

@matthieugallien does it mean Windows will try to store those with a PROPPATCH dav:displayname ?
I doubt so because one can likely only set a single text, not multiple ones

[PVince81]

ok, seems @starypatyk already tested on Windows so I guess we're good to go

[PVince81]

second review please @CarlSchwan @artonge @come-nc

[PVince81]

/backport to stable25

[DaphneMuller]

hello @starypatyk ,
Thank you for your work on this pull request! This ticket seems to have the tag 'missing documentation', is there any chance you could clarify what documentation is missing? Is this for admins or for app developers?

[starypatyk]

Hi @DaphneMuller,

The primary reason for submitting this PR was improving performance of the WebDAV queries. The change of behaviour was a side-effect.

Previously the dav:displayName property could be set for files and folders by a third-party client to any value - independent of the the file/folder name. Currently this property is always the same as the file/folder name and cannot be changed using the PROPPATCH request.

Having separate file name and displayName seems to be a very unusual use case. We are not aware of any WebDAV client doing such things.

The above might be mentioned in the developer documentation in Supported DAV properties section. However, when I read this section now, the description there seems to be closer to the current behaviour than to the previous one.

@PVince81 - any additional comments?

[DaphneMuller]

hello @starypatyk , thank you so much for your lightning fast and helpful reply! It sounds like the documentation is already pretty much done there. Thanks again for your great work. For now I will then remove the 'needs documentation' tag. Any objections @artonge @come-nc ?