[Bug]: client does not work when the server is forcing text/xml content type

[bohwaz]

⚠️ Before submitting, please verify the following: ⚠️

• This is a bug, not a question or a configuration issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
• I agree to follow Nextcloud's Code of Conduct

Bug description

As seen here:

desktop/src/libsync/discoveryphase.cpp

Line 591 in eeb0d20

&& !contentType.contains("application/xml; charset=utf-8")) {

There is a issue in the source code, as it is only expecting application/xml but a server may force to send text/xml (for example when you have a security proxy or something else).

Also if the header is Content-Type: application/xml; charset="utf-8" (note the quotes), the client will fail, even though this is perfectly valid header, as seen in the RFC: https://httpwg.org/specs/rfc7231.html#data.type

The NextCloud client should accept both text/xml and application/xml, as well as not failing if the charset value is using quotes.

Steps to reproduce

1. Right click on the file
2. Click on Share Options
3. The share dialog does not display the option to share by e-mail
   ...

Expected behavior

Accepting text/xml

Which files are affected by this bug

all

Operating system

Linux

Which version of the operating system you are running.

Debian

Package

Other

Nextcloud Server version

Doesn't matter

Nextcloud Desktop Client version

ALL

Is this bug present after an update or on a fresh install?

Fresh desktop client install

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

Are you using an external user-backend?

• Default internal user-backend
• LDAP/ Active Directory
• SSO - SAML
• Other

Nextcloud Server logs

No response

Additional info

No response

[bohwaz]

Thank you @mgallien :)