Bug 471730 - Evolution caldav encoding problem
Evolution caldav encoding problem
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: evolution (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Matthew Barnes
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-15 04:11 EST by Yovko Ilchev Yovkov
Modified: 2009-07-16 05:54 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-18 17:01:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Yovko Ilchev Yovkov 2008-11-15 04:11:13 EST
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:
Comment 1 Milan Crha 2008-11-18 14:09:24 EST
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.
Comment 2 Yovko Ilchev Yovkov 2008-11-18 14:26:50 EST
Hi Milan, 

It looks strange for me, because using Thunderbird, unicode appointments work correctly.
I will open request in Zimbra bugzilla.
Comment 3 Matthew Barnes 2008-11-18 14:47:46 EST
(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?
Comment 4 Milan Crha 2008-11-19 04:30:06 EST
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.)
Comment 5 Milan Crha 2008-11-19 06:32:13 EST
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.
Comment 6 Milan Crha 2008-11-19 06:37:06 EST
OK, as long as they are able to read it correctly, I will try to investigate further. Thanks for pointing this out. Reopening.
Comment 7 Matthew Barnes 2008-11-19 08:12:43 EST
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.
Comment 8 Milan Crha 2008-11-19 08:20:12 EST
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.
Comment 9 Milan Crha 2008-11-24 15:59:29 EST
(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.
Comment 10 Bug Zapper 2008-11-26 00:26:19 EST
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
Comment 11 Matěj Cepl 2009-01-31 16:46:28 EST
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.
Comment 12 Milan Crha 2009-02-02 05:25:48 EST
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.
Comment 13 Milan Crha 2009-05-18 17:01:33 EDT
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

Note You need to log in before you can comment on or make changes to this bug.