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