Mail not displaying in DIMP, was Re: Problems with Horde Interface after upgrade from 2.2.4 to 2.3.2

"Uwe Greßhake | dmmd GmbH & Co.KG" u.gresshake at dmmd.de
Tue Feb 21 14:09:32 CET 2012


Am 20.02.2012 23:25, schrieb Gunnar Wrobel:
>
> Zitat von "Uwe Greßhake | dmmd GmbH & Co.KG" <u.gresshake at dmmd.de>:
>
>> Am 28.06.2011 18:46, schrieb Christoph Wickert:
>>> On Tuesday 14 June 2011 11:28:43 Gavin McCullagh wrote:
>>>> Hi,
>>>>
>>>> On Tue, 14 Jun 2011, Christoph Wickert wrote:
>>>>>> How do I know which locales I need to install?  We're using British
>>>>>> English as the default language in Horde, or is this a question of
>>>>>> matching the locale of the email to display?
>>>>> AFAIK you need the language Horde is using in in both ISO* and 
>>>>> UTF8. grep
>>>>> php- errors.log for "function.json-encode" and give us the relevant
>>>>> parts please.
>>>> These seem to have been the relevant messages:
>>>>
>>>> [13-Jun-2011 13:18:33] PHP Warning:  json_encode() [<a
>>>> href='function.json-encode'>function.json-encode</a>]: Invalid UTF-8
>>>> sequence in argument in 
>>>> /kolab/var/kolab/www/client/imp/lib/JSON.php on
>>>> line 86
>>> For the record: We are now tracking this issue at
>>> https://issues.kolab.org/issue4743
>>>
>>> Thanks to everybody who helped us to debug this so far.
>>>
>>> Regards,
>>> Christoph
>>>
>>>
>>
>> This problem still exist in my fresh kolab installation of stable
>> release 2.3.4.
>>
>> Most mails are not displayed in dimp preview windows. Instead the error
>> message
>>    "Your server is unable to render UTF-8 message. The preview won't
>> work. Please contact your administrator."
>> is displayed. Not only the preview window is effected by this error:
>> Folder names, which contain non ASCII letters, are not displayed in the
>> folder list in dimp, if they belong to the functional folders on top of
>> the list (sent, trash, etc.). Non ASCII characters in From and Subject
>> lines of new mails are wrongly converted and then badly displayed in
>> other mail-clients.
>>
>> In all cases the the horde json code is involved and the json_encode()
>> error messages occur in the apache error log.
>>
>> I installed all necessary locales and restarted apache, but it does not
>> solve the problem.
>>
>> Then I tried different client operating systems and different browsers
>> and found out, that the error is independent of the client OS but it
>> depends on the browser. So for me it seems to be a client server issue.
>> I compared the browsers and the conversation between the browsers and
>> the server and examined, that the error occurs, if the browser does not
>> sent the "Accept-Charset"-Header. If the "Accept-Charset"-Header is
>> missing in the browser request, some code in the json libs in horde seem
>> to be irritated and suffers from an undefined state.
>>
>> My temporary workaround for affected firefox browsers is to install the
>> "Modify Headers"-Add On from Gareth Hunt and manually add the missing
>> header field.
>> I hope my analyse is helpful to solve this problem on server side.
>
> This sounds a bit like the recent issue introduced by the Firefox 10. 
> The attached patch might solve your problem.
>
> This is part of the newest Horde 3 release from about a week ago. That 
> release also fixed a few XSS issues that should probably be ported to 
> the OpenPKG based Kolab server. Though I would consider those 
> insignificant as compared to the DOS PHP holes that still allow to 
> take down an OpenPKG based Kolab server via z-push.
>
> Cheers,
>
> Gunar
>

Thanks Gunnar for this patch.
It solves the problem with Firefox 10 and Dimp, but for example not with 
the actual version 9 of Internet Explorer, and probably other actual 
browser versions, too. I took a deeper look into the file Browser.php 
and examined the member function match(). Now I know what a complex 
function is;-)
The member function setFeature('utf') is not called when IE9 accesses 
Dimp. The same effect happened with Firefox 10 before applying your patch.

To solve the problem in IE9 and newer upcoming versions of IE, I would 
suggest to change the case statement, which begins in line 450 into an 
if (>=...) elseif ... statement.

Best regards,
Uwe




More information about the users mailing list