Indicate forbidden_filename_characters in capabilities endpoint

[!TIP]

Help move this idea forward

• Use the 👍 reaction to show support for this feature.
• Avoid commenting unless you have relevant information to add; unnecessary comments create noise for subscribers.
• Subscribe to receive notifications about status changes and new comments.

Is your feature request related to a problem? Please describe.
We are developing the integration between OpenProject and Nextcloud. As part of that integration it's possible that "project folders" are automatically created in Nextcloud for each project a user creates in OpenProject. This involves OpenProject automatically making API calls to create folders in Nextcloud.

While this works well with many installations, it can fall apart when either of the following is true:

• forbidden_filename_characters are defined
• The NC31+ option to enable windows-compatibility mode is enabled

In this case projects that contain certain special characters (e.g. :) can't create their folder. While it would be possible to hardcode a list of characters (especially the windows ones), this solution is rather limited and might not work with all characters that might be forbidden in Nextcloud. Thus it would be great if our API client could discover what's allowed/forbidden on any given Nextcloud storage.

Describe the solution you'd like
Include the configured forbidden_filename_characters in the capabilities endpoint of Nextcloud, so that API clients can automatically discover which characters they need to avoid. The list of forbidden characters indicated there should probably be a combination of what's disallowed explicitly through the corresponding setting, but also implicitly via the "windows compatibility" mode introduced in NC 31.

Describe alternatives you've considered
Alternatively Nextcloud could perform replacements of such characters on its own, though I didn't check WebDAV specifications on this, but I could imagine that a lot of clients would break when you try to create a file/folder with one name and in response to that a file/folder with a different name is created.

Even if it was well supported by clients, it would risk taking agency away from clients (e.g. choosing how to react to forbidden characters... cut them out? replace them?).

Start by locating the Nextcloud capabilities endpoint implementation and then trace how forbidden_filename_characters and Windows compatibility mode determine allowed names. Confirm the capabilities response format and existing tests before deciding how the combined forbidden-character list should be exposed; done means API clients can discover the effective restrictions.