Open MetaEntropy opened 5 years ago
This is by design. Many CardDAV clients only support version 3.0, and the ones that support 4.0 tend to explicitly state this. Furthermore, clients that support 4.0 tend to also support 3.0.
Originally only 3.0 was supported. This was the only sane way to introduce vCard 4.0 support. I can imagine there might be a future where 4.0 has overwhelming support, but I don't think this is the case today. It's good to be explicit anyway.
bug description When an HTTP GET request is performed on a vCard, a content negotiation happens, based on the Accept header of the HTTP GET request.
If the Accept header does not explicitly contain "text/vcard; version=4.0", then, sabre/dav defaults to version 3.0 vCard, downgrading high quality vCards from its database. The '/' specified in common Web browsers (Firefox, Internet Explorer, Chrome) matches the version 3.0 vCard format too.
The root of this problem is in the negotiateVCard() function in lib/CardDAV/Plugin.php / matches text/vcard without a specific version number text/vcard without specific version number is interpreted as version 3.0 vCard.
vCard 4.0 is mature and widely supported. It should be the default version.
discussion RFC 6350 defines the text/vcard MIME type.
It does not specify a default text/vcard version. When none is specified, I think that sabre/dav should either default to version 4.0 (best format) or to the internally stored format (i.e. no conversion -> no data loss).
The following patch uses the first approach (defaulting to version 4.0). It is based on the code of Baikal 0.6.0 which may not be the most up to date.
vcard-HTTP-GET-defaults-to-version-4.0.patch.txt
steps to reproduce
Other solution (more powerful testing). Follow steps 1 and 2. Then, launch the command curl --basic --user XXXXX:XXXX -H 'Accept:/' http://example.com/baikal/html/card.php/addressbooks/john/default/test.vcf
See that the VERSION field is set to 3.0
related bug I first submitted this as a bug report to nextcloud https://github.com/nextcloud/server/issues/16922