Bug 471730
| Summary: | Evolution caldav encoding problem | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Yovko Ilchev Yovkov <yyovkov> |
| Component: | evolution | Assignee: | Matthew Barnes <mbarnes> |
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 10 | CC: | mbarnes, mcepl, mcrha |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-05-18 21:01:33 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I tried to reproduce this and it seems it's not Evolution's fault. I created an event with UTF-8 characters in summary in Evolution, sent this to the Zimbra server and looked to the web UI. The event is shown correctly there. Then I closed Evolution, cleared the local cache and run Evolution again, the event has been received from the server but shown incorrectly in the Evolution's UI. After a little investigation I found that Zimbra is sending the text already damaged, they are not encoded in UTF-8 or other encoding, there are already those question marks. I'm sorry, but in this case we are not able to do with this anything in Evolution. Hi Milan, It looks strange for me, because using Thunderbird, unicode appointments work correctly. I will open request in Zimbra bugzilla. (In reply to comment #1) > After a little investigation I found that Zimbra is sending the text already > damaged, they are not encoded in UTF-8 or other encoding, there are already > those question marks. Might want to use Wireshark to see what exactly Zimbra _is_ sending, if you haven't already. Perhaps we can work around the bug on the Evolution side? I checked the soap data, like when running evolution-data-server with CALDAV_DEBUG=all set. It shows question marks in the response body itself, but with other server it shows correct UTF-8 characters. Thus I believe in CantFix. I'll check with wireshark, just to be sure, maybe they send it in different encoding than UTF-8, which is supposed to be default encoding. (As I was told by karora, when I asked him on IRC; he pointed me to RFC2445 4.1.4 - for the specification that it is the default there.) I see my server is using https when connection to the calendar, thus the wireshark is not the option. Lets see what I can find with lightening. OK, as long as they are able to read it correctly, I will try to investigate further. Thanks for pointing this out. Reopening. Is the CalDAV backend using libsoup? If so, you might want to talk to Dan Winship about this. libsoup might need to pull some tricks from Camel's playbook regarding broken character encodings. OK, I found the difference and the issue is really with the Zimbra, or there is some hidden setup I'm not aware of. The difference between Lightning and Evolution is that Lightning requests calendar data with "calendar-query" request, but Evolution uses simple GET on the URI of the exact calendar item. It's correctly encoded in the calendar-query, because it's part of the XML, which is encoded in UTF-8 by default. Why it isn't properly encoded in the GET request I really do not know. As I said before, the other server I'm using, the rscds, is working fine. We can change Evolution's backend for CalDAV, but such change would be rather discussed with upstream developers. (In reply to comment #7) > Is the CalDAV backend using libsoup? If so, you might want to talk to Dan > Winship about this. libsoup might need to pull some tricks from Camel's > playbook regarding broken character encodings. Yes, it is using libsoup, but that isn't the case, because it works fine with the XML datas. (In reply to comment #2) > I will open request in Zimbra bugzilla. Can you point me to their bug report, please? I would like to know their opinion, just in case I do something wrong and they know what or whether they'll confirm. Thanks in advance. This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Reporter, could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. Actually, there is an upstream (zimbra) report about this, http://www.zimbra.com/forums/evolution-connector/24962-encoding-problems-utf8.html but it seems they do not care enough. Oh, I forgot of this, I'm sorry. Just realized [1] this is supposed to be fixed in Zimbra since 5.0.14, thus closing as upstream. [1] http://bugzilla.zimbra.com/show_bug.cgi?id=35906 |
Description of problem: I have configured evolution calednar against Zimbra with no using zimbra connector, but using caldav. Once I have create a new appointment in the calendar using via Zimbra web Interface, using UNICODE characters, when calendar is synchronized in evolution it appears only qustionmarks, not any readable symbols other than this. Version-Release number of selected component (if applicable): Evolution 2.24.1 Zimbra 5.0.10.GA How reproducible: Setup Zimbra server and connect Evolution calendar to it, using caldav. Steps to Reproduce: 1. Install Zimbra 5.0.10GA server 2. Configure evolution calendar: Calendar -> New Calendar -> Type: CalDAV -> Name: ConnectedToZimbra -> URL: caldav://your.zimbra.server.net/dav/username/Calendar/ -> Username: username 3. Make the calendar "Default calendar" and "Copy this calendar content localy for offline operations" 4. Create an Calendar entry via Zimbra Web UI on non - english language. (I am using Bulgarian) 5. Close and open again Evolution. Go to Evolution Calendar Actual results: The calendar entries occured as ????? not as letters you have typed in the Zimbra UI Expected results: The calendar entries should be human readble - to read the same as you have type in Zimbra UI. Additional info: