no utf encoding when subscribing to a remote calendar

When using kronolith to subscribe to a remote calendar that

Tue, 07 Dec 2010 12:53:40 +0000

When using kronolith to subscribe to a remote calendar that is also on kronolith (same or other server), all utf characters on events display incorrectly. I am currently using Horde Groupware Webmail Edition 1.2.7 I attach a screenshot of the problem. The two events shown are, the one that is displayed corrently in the local calendar and the one that is displayed incorrectly is from the same calendar when subscribed on it as remote calendar.

I found out that when retrieving the remote calendar, the ge

Tue, 07 Dec 2010 13:41:34 +0000

I found out that when retrieving the remote calendar, the generated HTTP request didn't specify any special headers, like the list of accepted character sets so I guess the response was served using a default encoding (ISO8859-1?) which breaks any unicode characters. I applied the attached patch and the problem seems to be resolved...

You are not using the Git version of Kronolith.

Tue, 07 Dec 2010 15:10:15 +0000

You are not using the Git version of Kronolith.

Updated horde installation to the latest Groupware Webmail e

Tue, 07 Dec 2010 15:38:38 +0000

Updated horde installation to the latest Groupware Webmail edition v1.2.9 and the problem still exists. You are right, it's not the Git version of Kronolith, but I checked the Git version and didn't see any changes regarding this, that's why I chose this queue, which is probably wrong... I can't see a way of changing the Queue Version... Should I report it again using a different Queue? Horde Groupware Webmail edition?

I can't reproduce this. Special characters are handled perfe

Tue, 28 Dec 2010 22:21:31 +0000

I can't reproduce this. Special characters are handled perfectly fine when subscribe a Kronolith calendar from another Kronolith instance.

I can reproduce it using a command line to manually generate

Wed, 29 Dec 2010 10:57:38 +0000

I can reproduce it using a command line to manually generate a similar request using curl. Using the following command: ~# curl --basic -u calendar:XXXX -v "http://127.0.0.1/rpc.php/kronolith/calendar/calendar.ics" * About to connect() to 127.0.0.1 port 80 * Trying 127.0.0.1... * connected * Connected to 127.0.0.1 (127.0.0.1) port 80 * Server auth using Basic with user 'calendar' > GET /rpc.php/kronolith/calendar/calendar.ics HTTP/1.1 Authorization: Basic Y2FsZW5kYXI6Y0BsM25kQHI= User-Agent: curl/7.12.2 (i686-pc-linux-gnu) libcurl/7.12.2 OpenSSL/0.9.7l zlib/1.2.2 Host: 127.0.0.1 Pragma: no-cache Accept: */* < HTTP/1.1 200 OK < Date: Wed, 29 Dec 2010 10:29:53 GMT < Server: Apache < Set-Cookie: Horde=9083da515b573f377284c524da38d192; path=/; domain=127.0.0.1 < Expires: Thu, 19 Nov 1981 08:52:00 GMT < Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 < Pragma: no-cache < X-Dav-Powered-By: Horde WebDAV Server < Set-Cookie: imp_key=9083da515b573f377284c524da38d192; path=/; domain=127.0.0.1 < Set-Cookie: auth_key=9083da515b573f377284c524da38d192; path=/; domain=127.0.0.1 < Last-modified: Wed, 29 Dec 2010 10:29:53 GMT < Content-length: 554 < X-WebDAV-Status: 200 OK < Content-Type: text/calendar BEGIN:VCALENDAR VERSION:2.0 X-WR-CALNAME:calendar's Calendar PRODID:-//The Horde Project//Horde_iCalendar Library\, Horde 3.3.11//EN METHOD:PUBLISH BEGIN:VEVENT DTSTART:20101207T040000Z DTEND:20101207T050000Z DTSTAMP:20101229T102953Z UID:20101207111532.10353qlamyyxehyc@213.140.132.32 CREATED:20101207T091532Z LAST-MODIFIED:20101207T091532Z SUMMARY:event ?? ???????? ORGANIZER;CN=calendar:mailto:calendar DESCRIPTION:???????? ?????????.\n???????????\n???lalalslasl CLASS:PUBLIC STATUS:CONFIRMED TRANSP:OPAQUE END:VEVENT END:VCALENDAR * Connection #0 to host 127.0.0.1 left intact * Closing connection #0 In this case the output is misformated... utf characters are converted to ? (An effort is made to convert the output to ISO-8859-1). Adding an appropriate 'Accept-Charset' header fixes the problem and the server response is utf-8 encoded as it should : ~# curl --basic -u calendar:XXXX -v -H 'Accept-Charset: utf-8' "http://127.0.0.1/rpc.php/kronolith/calendar/calendar.ics" * About to connect() to 127.0.0.1 port 80 * Trying 127.0.0.1... * connected * Connected to 127.0.0.1 (127.0.0.1) port 80 * Server auth using Basic with user 'calendar' > GET /rpc.php/kronolith/calendar/calendar.ics HTTP/1.1 Authorization: Basic Y2FsZW5kYXI6Y0BsM25kQHI= User-Agent: curl/7.12.2 (i686-pc-linux-gnu) libcurl/7.12.2 OpenSSL/0.9.7l zlib/1.2.2 Host: 127.0.0.1 Pragma: no-cache Accept: */* Accept-Charset: utf-8 < HTTP/1.1 200 OK < Date: Wed, 29 Dec 2010 10:30:24 GMT < Server: Apache < Set-Cookie: Horde=c8491bb24b20d1189241c065752bd59a; path=/; domain=127.0.0.1 < Expires: Thu, 19 Nov 1981 08:52:00 GMT < Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 < Pragma: no-cache < X-Dav-Powered-By: Horde WebDAV Server < Set-Cookie: imp_key=c8491bb24b20d1189241c065752bd59a; path=/; domain=127.0.0.1 < Set-Cookie: auth_key=c8491bb24b20d1189241c065752bd59a; path=/; domain=127.0.0.1 < Last-modified: Wed, 29 Dec 2010 10:30:24 GMT < Content-length: 595 < X-WebDAV-Status: 200 OK < Content-Type: text/calendar BEGIN:VCALENDAR VERSION:2.0 X-WR-CALNAME:calendar's Calendar PRODID:-//The Horde Project//Horde_iCalendar Library\, Horde 3.3.11//EN METHOD:PUBLISH BEGIN:VEVENT DTSTART:20101207T040000Z DTEND:20101207T050000Z DTSTAMP:20101229T103024Z UID:20101207111532.10353qlamyyxehyc@213.140.132.32 CREATED:20101207T091532Z LAST-MODIFIED:20101207T091532Z SUMMARY:event ???µ ?µ?»?»?·?½?????¬ ORGANIZER;CN=calendar:mailto:calendar DESCRIPTION:???»?»?·?½?????® ? ?µ????³??±???®.\n???£?????µ???????½?µ??\n?????»lalalslasl CLASS:PUBLIC STATUS:CONFIRMED TRANSP:OPAQUE END:VEVENT END:VCALENDAR * Connection #0 to host 127.0.0.1 left intact * Closing connection #0 If you do this test, do you get different results? The server's response is not the problem, server responds as it should according to rfcs (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html), but the problem is in the request. When kronolith subscribes to the remote calender is making a request identical to the first one, and not the second one, and that's what's causing the problem. Using a browser to make the same request works fine, cause the browser sends an Accept-Charset header in the request anyway. Thank you for your consideration

I get a valid UTF-8 encoded response back from the server, w

Wed, 29 Dec 2010 15:26:37 +0000

I get a valid UTF-8 encoded response back from the server, which is what you expect from a text/calendar response, if not specified otherwise. Maybe you don't have UTF-8 locale support on your system?

I played with several options in the apache configuration (A

Thu, 30 Dec 2010 13:51:12 +0000

I played with several options in the apache configuration (AddDefaultCharset, AddCharset) in order to force apache to serve the response in the correct encoding (utf-8). While this works for files stored on the local filesystem (a simple text .ics file), it doesn't affect the php's response produced by kronolith. So, just to clarify your previous response, when you do the test with the 2 requests (one with an Accept-Charset header and one without) you still get the same valid UTF-8 encoded response? That shouldn't be happening... I think that by default an HTTP text/* response is ISO-8859-1 and not UTF-8, unless otherwise specified. (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1) What I'm trying to say is that the request generated by kronolith should specify an Accept-Charset header in order to get the correct response from the server. Thank you for everything and I wish you all a happy New Year :)

Cannot reproduce.

Fri, 01 Jul 2011 20:25:19 +0000

Cannot reproduce.