Re: Patch for fixing empty body messages in RU mailing list

From: Date: Mon, 03 Jan 2011 10:29:17 +0000
Subject: Re: Patch for fixing empty body messages in RU mailing list
References: 1 2  Groups: php.webmaster 
Request: Send a blank email to php-webmaster+get-10189@lists.php.net to get a copy of this message
2010/12/30 Hannes Magnusson <hannes.magnusson@gmail.com>: > On Thu, Dec 30, 2010 at 14:32, Alexey Shein <confik@gmail.com> wrote: >> There is a bug with hiding mail body messages on ru mailing list, like >> these ones: http://news.php.net/php.doc.ru/1205, >> http://news.php.net/php.doc.ru/1196, >> http://news.php.net/php.doc.ru/1198. >> So it seems i fixed it, but have no karma to commit it myself, so >> here's the patch (quite trivial). Please commit it or give me the > > > Are you sure it doesn't break anything else? > This change looks very odd to me. > > -Hannes > Ok, here is the explanation. The email rendering code is like this: while(!feof($s)) { $line = fgets($s); ... $line = $linebuf . $line; if (substr($line, -2) == "\r\n") { $linebuf = ''; } else { $linebuf = $line; continue; } ... echo $line; } So it seems to collect strings into one paragraph ($line variable) for further processing like highlighting quotes, links and etc. As Gmail uses base64 content-transfer-encoding and I'm on ubuntu, so it seems to encode linux line endings \n into the message body and this code expects lines (after unpacking base64 or quoted-printable) to end via \r\n which is not the case in my letters. That's why every time it executes "else" branch with continue statement and execution skips echoing the whole message. The code is ugly and very complicated so I tried to minimize my changes. I modified patch to include mac line endings (but can't test it since i don't have a mac :)) and fixed one more bug with parsing UTF-8 encoding from content-type header. So the solution is to change line if (substr($line, -2) == "\r\n") { to if (in_array(substr($line, -1), array("\n", "\r"))) { so it can handle last character in line is either \n or \r which covers all combinations of \n, \r\n and \r, while the previous patch checked only for \n and \r\n. -- Regards, Shein Alexey

Index: article.php =================================================================== --- article.php (revision 307013) +++ article.php (working copy) @@ -47,7 +47,7 @@ if ($inheaders && ($line == "\n" || $line == "\r\n")) { $inheaders = 0; if (isset($headers['content-type'])) { - if (preg_match('/charset=(["\']?)(\w+)\1/i', $headers['content-type'], $m)) { + if (preg_match('/charset=(["\']?)([\w-]+)\1/i', $headers['content-type'], $m)) { $charset = trim($m[2]); } @@ -161,7 +161,7 @@ $line = $linebuf . $line; - if (substr($line, -2) == "\r\n") { + if (in_array(substr($line, -1), array("\n", "\r"))) { $linebuf = ''; } else { $linebuf = $line;
« previous php.webmaster (#10189) next »