|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #75923 Body is fetched without the last line
Submitted: 2018-02-06 11:37 UTC Modified: -
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: jochem dot blok at fasterforward dot nl Assigned:
Status: Open Package: mailparse (PECL)
PHP Version: 5.6.33 OS: Ubuntu
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
Solve the problem:
3 + 25 = ?
Subscribe to this entry?

 [2018-02-06 11:37 UTC] jochem dot blok at fasterforward dot nl
With a not multipart mail the body is fetched without the last line. Appending a new line to the end "solves" the problem.

Test script:

ini_set('display_errors', 1);
header('Content-type: text/plain');

$tekst = <<<EOD
Subject: An RFC 822 formatted message

This is the plain text body of the message. Note the blank line
between the header information and the body of the message.

$stream = fopen('php://memory', 'r+');
fwrite($stream, $tekst);
fseek($stream, 0);
$resource = mailparse_msg_create();
mailparse_msg_parse($resource, fread($stream, 10000));

echo mailparse_msg_extract_part($resource, $stream);

Expected result:
This is the plain text body of the message. Note the blank line
between the header information and the body of the message.

Actual result:
This is the plain text body of the message. Note the blank line


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2018-03-17 15:17 UTC] pudge601 at hotmail dot com
I’ve tried to look into this myself and see if I can come up with a solution.

Disclaimer - I’m not a C dev, and have very little knowledge of PHP internals/extensions

The crux of the issue is that mailparse will only process a line when it gets to a new line character, so for an email string/file which doesn’t end with a new line, the last line will not be processed.

I tried to fix this by making it “flush” when we get to EOF, but this solution would only work when parsing files. The mailparse_msg_parse function (for parsing the mail as a string) can be called multiple times to parse the mail incrementally, and so there is no way for the extension to know whether it has reached the end of the mail string.

The only solutions I can think of for this (short of completely re-designing the API for parsing mail messages) would be;

1. Add a mailparse_msg_parse_flush function, which would process the remainder of contents in the buffer as if it is the last line. This would put the onus on the user to make sure they always call this function after calling mailparse_msg_parse
2. Automatically “flush” the buffer the first time any other function which works on a mime mail resource is called by the user; i.e. assume that if the user is trying to query about any aspect of the mime mail (get structure, get part data, get part), then they have finished passing in the raw data and anything left in the buffer is the end of the contents

Both of these approaches would probably then need to add restrictions on calling mailparse_msg_parse after flushing the buffer.

Given that these solutions aren’t particularly great, perhaps it would be better to just accept the current behaviour and document it. After all, the behaviour of only considering a line to be a line if it ends with a newline character is technically correct (as far as POSIX is concerned). The only trouble with this is that it isn’t possible to ever have a non-multipart mail whose body contents do not end in a newline, and for it to be parsed correctly by the mailparse extension (except if the contents are base64 encoded, in which case the raw newline is ignored).
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Sat Sep 21 13:01:27 2019 UTC