radicale upload VCARD2.1 failed #1238
Comments
|
Same problem here, exported contacts, tried to upload it to radicale and fails with Debian 11, Nginx, HTTP2, Radicale 3.1.5 |
|
I can confirm this is still happening on 3.1.7.0, Running Docker on Unraid. |
|
I've been trying to upload my contacts (vCard 3.0) and I get the same thing. [edit] Since there's been no activity on this project since July 14, I guess this isn't the solution I was looking for. |
|
I was able to fix this by commenting the following lines from the vobject package def decode(cls, line):
"""
Remove backslash escaping from line.valueDecode line, either to remove
backslash espacing, or to decode base64 encoding. The content line should
contain a ENCODING=b for base64 encoding, but Apple Addressbook seems to
export a singleton parameter of 'BASE64', which does not match the 3.0
vCard spec. If we encouter that, then we transform the parameter to
ENCODING=b
"""
if line.encoded:
if 'BASE64' in line.singletonparams:
line.singletonparams.remove('BASE64')
line.encoding_param = cls.base64string
encoding = getattr(line, 'encoding_param', None)
if encoding:
if isinstance(line.value, bytes):
line.value = codecs.decode(line.value, "base64")
# else:
# line.value = codecs.decode(line.value.encode("utf-8"), "base64")
else:
line.value = stringToTextValues(line.value)[0]
line.encoded = FalseThe encoding gets all wonky when BASE64 is used for the encoding param. I am not sure why and I am sure this quick fix breaks other cases, but it allows me to use base64 encoding on photos now so that's all that matters for me. |
|
"radicale" depends in this case 100% on vobject -> one has to wait until "vobject" got proper fixed |
|
I have constructed an example vCard, using the first quoted template above, and current vObject parses it without any problem. The code segment above is a little dubious, in several ways, but ... for data that is properly BASE64 encoded, the encoding of the string value to bytes will change nothing (since BASE64 is pure ASCII, and pure ASCII encoded as UTF-8 is byte-wise identical). It'd be great if one of the reporters (@osnosn, @Fijxu, @quamok, @slyduda) could provide the Radicale log file showing one of these failed imports -- it'd be really useful to see exactly how it's failing. |
|
|
Is this special vcard passing the validator without any errors? Please check with https://icalendar.org/validator.html |
|
Thanks for the further info, @yangtfu! The line that reports a parsing problem: run through which ... doesn't look like it'd be a valid vCard line. It's not valid UTF-8 either. So I'm not sure what it's trying to do. Could you please copy the whole problematic vCard into a comment? Maybe it's a continuation line or something ... With the complete input, hopefully we can figure this out. |
|
|
@yangtfu, I've run into a couple of issues testing that card. First, it's missing the Next, if I add a Last, the problematic string |
Resolves the parsing issue in Kozea#1238.
|
Thanks @yangtfu, that's very helpful. I am able to reproduce the problem. @pbiering, the problem is here: If that's changed to I'm also unaware of any past issues this might have had in Radicale: perhaps it's disabled for a reason here? Either way, I've sent a PR (#1476) with the above change. It's had no testing in Radicale. |
|
Thank you for tracing down the issue.
Potentially nobody so far was aware about.
Can you create a 2nd PR with extending the test cases? |
pbiering
added
improvement
and removed
need:reporter feedback
|
PR merged, please test. Once test case is added, this issue can be closed. |
The key is the QP continuation line for the URL, which (unlike vCard) doesn't indent, but uses a trailing '='. Parsing this needs the vobject.readComponents() call to have its allowQP flag True, as implemented in Kozea#1476.
In debian11,
apt install radicateinstalled radicate-3.0.6.when I upload a VCF file via browser, it failed.
This is the VCF file:
I changed VCF file, then upload OK.
The text was updated successfully, but these errors were encountered: