Pick vCard version by url parameters

[MetaEntropy]

vcard-defaults-to-v4.patch.txt

Describe the bug

When downloading a VCF file from the CardDAV with the HTTP GET verb from a common web browser (Firefox, Chrome, Internet Explorer) one would expect to

get a version 4.0 vCard, which is the best format supported by the CardDAV; nextcloud returns a version 3.0 vCard, downgrading the content.

This is due to the fact that most browsers do not explicitly add "text/vcard; version=4.0" on their "Accept" HTTP header line; in place they use /.
Consequently, the negotiateVCard() function called by httpAfterGet() in the 3rdparty/sabre/dav/lib/CardDAV/Plugin.php script negotiates the content

type as "text/vcard" then the text/vcard content type defaults to version 3.0.

The same behavior is observed for a "Accept: text/vcard" header.
To get a version 4.0 vCard, one has to set "Accept: text/vcard; version=4.0" explicitly in the header of the HTTP GET request.

Actually, RFC 6350, in section 10.1, defines the "text/vcard" type but does not tell that it defaults to version 3.0.

RFC 6350 section 10.1 contains the following paragraph

Interoperability considerations: The text/vcard media type is
intended to identify vCard data of any version. There are older
specifications of vCard [RFC2426][vCard21] still in common use.
While these formats are similar, they are not strictly compatible.
In general, it is necessary to inspect the value of the VERSION
property (see Section 6.7.9) for identifying the standard to which
a given vCard object conforms.

It seems that defaulting to version 4.0 would be better since most tools work with version 4.0 nowadays.

To Reproduce (easy way)
Steps to reproduce the behavior (way 1):

1. Login to nextcloud as a user on a common browser (tested on: Firefox, Internet Explorer, Chrome)
2. Click on the "Contacts" application
3. Click on any contact in order to open it (or create one if none exists)
4. Click on the menu (three dots icon) of the contact
5. Click "Download"
6. In the browser, Save the file on the disk
7. Open the file with a text editor
8. See that the "VERSION" field of the contact is 3.0 while it should be 4.0

To Reproduce (complex way, but easier to debug)

1. Reproduce steps 1 to 5 of the easy way

2. copy the URL such as http://example.com/owncloud/remote.php/dav/addressbooks/users/john/contacts/7a77045a-ff45-44d6-8f46-5294d600269a.vcf

3. Use the curl command:
   curl --basic --user XXXXXX:XXXXX -X GET -H 'Accept: /' http://example.com/owncloud/remote.php/dav/addressbooks/users/john/contacts/7a77045a-ff45-44d6-8f46-5294d600269a.vcf

4. Read the output

5. See that the "VERSION" field of the contact is 3.0 while it should be 4.0

Expected behavior
A version 4.0 file is expected with a field "VERSION:4.0"

Actual behavior
A version 3.0 file is observed with a field "VERSION:3.0"

Comments
The attached patch changes the behavior of HTTP GET requests on vCards. It does not affect REPORT requests since these requests use the negotiateVCard function

but first get the version from an XML attribute in the HTTP request body (defaulting to version 3.0).

Client configuration

Firefox 68

Windows 7 (6.1.7601 SP1)

CardDAV-clients:
Nextcloud Contacts web interface (application for nextcloud)
DAVx5 (backend) + builtin Contacts application in Android 4.4 (frontend)
(does not really matter)

[kesselb]

Thanks for your research 👍

Could you submit the patch upstream to https://github.com/sabre-io/dav? If they accept the patch we can backport it to https://github.com/nextcloud/3rdparty/tree/master/sabre/dav.

cc @georgehrke fyi

[MetaEntropy]

Thank you.
This bug has been submitted upstream:
sabre-io/dav#1190

[MetaEntropy]

The upstream patch has not been accepted. Defaulting to version 3.0 is intentional.
It makes sense for CardDAV clients. Indeed vCard clients are likely to declare support of version 4.0 of they do support it ; web browsers are different beasts with a generic Accept line.
I would expect the Nextcloud Contacts application to provide a way to download a vCard 4.0 in a web browser.
In my opinion, this is possible without breaking compatibility: generate an augmented URL with explicit vCard version specification for all VCF entries, bypassing HTTP Accept headers.
The Nextcloud Contacts application would provide two links (v3 and v4) so that the end user can choose the format.

[kesselb]

Sounds like an enhancement for the contacts app then.

cc @skjnldsv I moved this here and changed the title.

[skjnldsv]

@kesselb the vcard implementation is on server, contacts only read the data from the carddav backend 🤔

[kesselb]

Hmm 🙈 If I understand @MetaEntropy correctly then the server already returns a vCard 4.0 if we request it (by Accept: text/vcard; version=4.0). I'm not sure how the contacts app request the vcards.

[skjnldsv]

We just let the user open the direct link to a new tab :p

[kesselb]

Oh. We need to move it back then? Is it a bug or enhancement?

generate an augmented URL with explicit vCard version specification for all VCF entries, bypassing HTTP Accept headers.

This needs to be done for the carddav server?

[skjnldsv]

No idea, on contacts the download button is just a link to the /remote.php/dav/users/xxx/addressbook/filename.vcf