From: <tr...@eg...> - 2013-04-04 09:48:58
|
Ticket modified by Klaus Leithoff at 2013/04/04 11:48 Tracking System - Bugs Category - FelamiMail Version - Trunk Status - Pending Resolution - Fixed Completed - 100% Priority - 5 - medium Created by - Uwe Redecker Created on - 2013/02/24 11:37 Assigned to - Klaus Leithoff Summary - #3212 - Sometimes json_encode failure in html-view of emails. Hi, sometimes viewing of some emails generates an error : In the peview windows and the email-window is only shown : null !!! In the php-error-log is the following message : [24-Feb-2013 09:33:06 Europe/Berlin] PHP Warning: json_encode(): Invalid UTF-8 sequence in argument in G:\Programme\Apache24\htdocs\egroupware\felamimail\inc\class.uidisplay.inc.php on line 1130. The relevant code : " var email_content_$hash = ".json_encode($frameHtml)."; function $funcname(_tar) { if (typeof _tar != \"undefined\" && _tar && typeof _tar.contentWindow != \"undefined\" && _tar.contentWindow != null && typeof _tar.contentWindow.egw_instant_load != \"undefined\") { _tar.setAttribute(\"scrolling\", \"no\"); // Workaround for FF 3.5 _tar.contentWindow.egw_instant_load(email_content_$hash); _tar.setAttribute(\"scrolling\", \"auto\"); } } "; After restarting the web-server everything is OK, the email is displayed normaly .... for a small time ... then the error comes back. The error occurs in every browser except in normal email programs such as Thunderbird or Outlook ... The system is installed on a Windows-Server 2k3. The Patchlevel of eGroupware is r41830. Apache 2.4.3 (win32) ; PHP 5.4.11. Any hints or suggestion to solve this? Grettings, Uwe Redecker Comment by Klaus Leithoff at 2013/04/04 11:48: I found some strange thing, when iconv engine is not glibc we could see the problem on ralfs machine. was triggered by using the tidy option in HTMLawed. I implemented some routine to handle that. (rev 42154) Could you test/verify if your problem is solved with that as well? Comment by Klaus Leithoff at 2013/03/12 12:17: What I do find interesting is: [www.resellerdirect.de/track_openings.php?daily_mail=281 Returns a 500 (Internal Server Error) If this one is not failing, but returning Crap (or non UTF-8 stuff) in your case, then we may have some explanation for your error. Comment by Klaus Leithoff at 2013/03/12 12:09: tested it on my windows machine: cant reproduce it here either its a PHP Version 5.4.3 (running under XAMPP) Can you reproduce it, when registering for an EPL-Trial and accessing your Mailbox with a userdefined account from there? Comment by Klaus Leithoff at 2013/03/12 10:49: Those 2 testmails imported correctly and without warning in Thunderbird. They displayed without causing problems, and without throwing warnings! I have a EGW Windows Installation on one of my machines. I will try with that one, but by now: no idea what is causing the failure for you. Comment by Klaus Leithoff at 2013/03/12 10:41: agreed, but i wonder why it happens to you and not to me on my various systems i tested it with Comment by Uwe Redecker at 2013/03/12 10:27: Hi Klaus, I add two more bad emails ... "ChannelAlert- SOS, ActionIT, TAROX, DEVIL, Michael, BHS Binkert und mehr.eml" and "Paketwaage bis 200 Kilo digital Edelstahl nur 78,35.eml" which also produce the error : null in html-view. It's a strong effect, that an email could shoot down the view ! Comment by Klaus Leithoff at 2013/03/11 13:26: Sorry, cannot reproduce that :-( So its hard to fix. Comment by Klaus Leithoff at 2013/02/26 12:41: Importing of the mail resulted in strange message from one of "my" mailservers: message contains bare lines, and refused to import. On another mailserver I was able to import, so this remains strange. Comment by Klaus Leithoff at 2013/02/26 12:17: So this is telling me that json_encode in line 1506 seems not to fail. So why is it failing later on? I will check with the mail, but later that day. Comment by Uwe Redecker at 2013/02/26 10:17: Hi Klaus, i attached 2 files. The eml-file of the "bad" eMail, and the PHP-ERROR.LOG if line 1507 uncommented. Uwe Comment by Klaus Leithoff at 2013/02/26 09:23: could you test for me, if the mail processing passes by line 1507 by uncommenting the error_log statement there. depending on your php version json_last_error is available or not (PHP 5 >= 5.3.0) If its not comming past that line, the displayCharset is not UTF-8. Then you should check what is returned by translation->charset() in line 99. Would you mind attaching the eml file of that problemmail? seems to be a newsletter. Comment by Uwe Redecker at 2013/02/26 08:15: Hi Klaus, I tested out a few things: - If I forward or answer a broken email I can see the content ! ( but the forwarding text has text coding errors ) See attached files : forwarding-bad-email.jpg, bad-email-view.jpg. Funny ! Greetings Uwe Redecker Comment by Uwe Redecker at 2013/02/25 20:53: Hi Klaus. I just tested the hint with "return "";" No change! The error must be somewhere else. :( Comment by Klaus Leithoff at 2013/02/25 12:06: does not seem to hold non compatible UTF-8 chars. Try returning an empty string, instead of the additionalStyle stuff. return ""; just after the error log. If the problem persists, we must look somewhere else. Comment by Uwe Redecker at 2013/02/25 11:52: Hi Klaus, I enabled the logging in line 1061, the result is attached as file "20130225 php-errors.log" I'm not sure if dieses helps. A little perplexed, Uwe Redecker Comment by Klaus Leithoff at 2013/02/25 09:25: Hi Uwe, getdisplayableBody already tests this (non UTF8 Chars in Body). Line 1503 to 1516 There is only one way to traverse this: by adding the styles that may be included by the eMail. But: if you restart your WebServer, and everything works, for that particular eMail, the problem seems to be connected not only to the content of the Mail, but some other factors too. There is a comment for error_logging in Line 1061. Please uncomment that, so you may see what is the possible input causing the problem. Best regards Klausi Comment by Ralf Becker at 2013/02/24 12:11: Hi Uwe, problem is probably mails which claim to be utf-8, but are not, at least not entirely. PHP JSON encode will not return anything, if there's a single non utf-8 char in it! To fix that situation for mail (dont think we need or want it in general), fmail could check if encoding failed (json_last_error() == JSON_ERROR_UTF8) and then clean, mail content with regular expression described in magp.ie/2011/01/06/remove-non-utf8-characters-from-string-with-php/ -> http://www.resellerdirect.de/track_openings.php?daily_mail=281] Maybe for external mail content, we could also think about doing that anyway, as mailformed utf-8 chars have some exploit potential. Ralf Linked entries: https://community.egroupware.org/egroupware/index.php?menuaction=tracker.tracker_ui.edit&tr_id=3212&no_popup=1 |