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

From: Date: Wed, 19 Jan 2011 20:13:26 +0000
Subject: Re: Patch for fixing empty body messages in RU mailing list
References: 1 2 3  Groups: php.webmaster 
Request: Send a blank email to php-webmaster+get-10450@lists.php.net to get a copy of this message
Kalle.. Since you are playing with newsweb.. Could you look at this? -Hannes On Mon, Jan 3, 2011 at 11:29, Alexey Shein <confik@gmail.com> wrote: > 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 >

« previous php.webmaster (#10450) next »