Closed Bug 984314 Opened 8 years ago Closed 8 years ago

With CalDAV-Sync, Lighting includes '@<hostname>' in the UID, which possibly breaks other clients


(Calendar :: Provider: CalDAV, defect)

Lightning 2.6
Not set


(Not tracked)



(Reporter: bugzilla-mozilla, Unassigned)


(Whiteboard: [calconnect31])

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20140212131424

Steps to reproduce:

Set up a radicale 0.8 server
Use Thunderbird 24.x + Lighting 2.6x
Add radicale as CalDAV server
Create event on server
Browse .ICS file on server, see that UID has '<something>@<hostname>'
Try to sync with different client, e.g. DavDroid and see it break

I originally opened this issue on the DavDroid-Tracker at:
And was told that its probably bad style of the calendar client itself (in this case, lighting) adding events that might produce such URLs. So i came here ;).
Quoting RFC2822 (the user) from this issue:
========= SNIP =========
 1. SoGo shouldn't PUT ics files with "@" in the file name to the server, but only use %40 [(Please) Stop Using Unsafe Characters in URLs]
2. Radicale should convert the @ to %40 automatically.
3. Regardless of Radicale converts @ to %40 internally, it should always treat @ and %40 the same.
========= SNAP =========

Please note that "SoGo" should be "Lighting" as i was not aware that lighting itself offered CalDAV support and wrongly thought it was the SoGo plugin...

Actual results:

UIDs containing an unencoded '@' have been pushed to the server, possibly breaking other clients.

Expected results:

UIDs should, as far as i understand, not contain unencoded '@'s. For more information please refer to the statements of the DavDroid author at the bug listed above.

-Dario Ernst
OS: All → Linux
Hardware: All → x86_64
Whiteboard: [calconnect31]
I've tested this and I don't see an issue with Lightning here:

* Lightning itself doesn't create new events with a @ in the UID
* I've tested setting the UID to "a@b" with a debugger and then sending the request
   -> The Mozilla platform correctly encodes this to "a%40b"
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.