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

From: Date: Wed, 02 Feb 2011 06:32:07 +0000
Subject: Re: Patch for fixing empty body messages in RU mailing list
References: 1 2 3 4  Groups: php.webmaster 
Request: Send a blank email to php-webmaster+get-10494@lists.php.net to get a copy of this message
Any news here? 2011/1/20 Hannes Magnusson <hannes.magnusson@gmail.com>: > 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 >> > -- Regards, Shein Alexey

« previous php.webmaster (#10494) next »