Re: Patch for fixing empty body messages in RU mailing list
| From: | Hannes Magnusson | 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
>