Radicale backslash-escapes in URIs which breaks vCard 4.0 esp. PHOTO

[haraldrudell]

Radicale rewrites uploaded vCards and uses backslash escapes in violation of rfc 6350

in the below, on return the semicolon preceding base64 is escaped with backslash Radicale 3.8.1

BEGIN:VCARD
VERSION:4.0
FN:a
UID:urn:uuid:958f809e-a0b4-4918-bede-b7d01602bab7
PHOTO:data:image/jpeg;base64,/9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAMCAgMCAgMDAw
 MEAwMEBQgFBQQEBQoHBwYIDAoMDAsKCwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/w
 AALCAABAAEBAREA/8QAFAABAAAAAAAAAAAAAAAAAAAACf/EABQQAQAAAAAAAAAAAAAAAAAAAAD/
 2gAIAQEAAD8AKp//2Q==
END:VCARD

only abnf to use backslash escapes: comes down to VALUE=TEXT, and properties N ADR. semicolon escape is only in N ADR

URI, eg PHOTO, is not part of backslash escaping

TEXT-CHAR = "\\" / "\," / "\n" / WSP / NON-ASCII
               / %x21-2B / %x2D-5B / %x5D-7E
        ; Backslashes, commas, and newlines must be encoded.

     component = "\\" / "\," / "\;" / "\n" / WSP / NON-ASCII

https://www.rfc-editor.org/rfc/rfc6350#section-3.4 https://www.rfc-editor.org/rfc/rfc6350#section-4

response

BEGIN:VCARD
VERSION:4.0
UID:urn:uuid:958f809e-a0b4-4918-bede-b7d01602bab7
FN:a
PHOTO:data:image/jpeg\;base64
END:VCARD

[pbiering]

Radicale depends for parsing items on vobject which looks like still misses proper vcard 4.0 support

Upload is working with 3.0 format (see also related test content https://github.com/Kozea/Radicale/blob/master/radicale/tests/static/contact_photo_with_data_uri.vcf)

- PHOTO:data:image/jpeg;base64,/9j/4AAQ...
+ PHOTO;ENCODING=b;TYPE=jpeg:data:image/jpeg;base64,/9j/4AAQ...

Internally this changes from 'photo': [<PHOTO{} (BINARY PHOTO DATA at 0x139824828307312) >]} to 'photo': [<PHOTO{'ENCODING': ['b'], 'TYPE': ['jpeg']} (BINARY PHOTO DATA at 0x139824827934096) >]}

which version of vobject is in use on your side? I can at least replicate the issue with 0.9.8

-> please file ticket to https://github.com/py-vobject/vobject/

[haraldrudell]

pretending that vCard 3.0 is somehow good enough is not a winning strategy

vCard 4.0 offers synchronization support that Radicale doesn’t have

vCard 4.0 rfc 6350 is only 74 pages published 14 years ago. It can be implemented inside of a week

re-parsing vCards is poor practice because the increased likelihood that bugs in the server will completely fail the client and what the customer is trying to do. It also forcefully removes the customer’s control over his data. It also opens for ping-pong bugs between server and client-code. They say there is some python reason for the re-parse

• it is reasonable that an uploaded strictly parsing unicode text 4.0 vCard to not be re-encoded
• in 4.0, content-lines depend on the property introducing 30 rules not in 2.1 3.0. portable parsing becomes bug-prone. 4.0 should have its own minimalistic code path

this ticket can be closed.

Radicale looked for a while but it’s garbage like almost all open-source vCard code

Thanks anyway. I am trying to avoid writing everything myself

My humble suggestion is that Radicale writes its own strict 4.0 parser and uses this code-path for 4.0, then comes up with some trick to avoid the re-parse. A server setting provides on-the-fly 4.0 migration to eradicate 2.1 3.0. Any item short of strict 4.0 parsing goes to best-effort legacy code

• 3 parts: a portable version parser, line-unfolder and content-line parser. That’s it

[pbiering]

there are no plans that Radicale will implement it's own vcard parser, all such efforts should go into vobject.

I kee this ticket open until vobject is enriched with such support.

[da4089]

vCard 4.0 support is very high on vobject's todo list.

We need to fix up some lingering string/byte issues from the Python3 transition first.

[da4089]

Relevant vobject issue: py-vobject/vobject#29

[bitwombat]

@haraldrudell Check yourself mate. Completely uncalled for tone and attitude. Radicale is provided free to the public by the good graces of the author(s). Like all open source software. Be polite and thankful or don't write anything.