problematic implementation of getMessageBody
GoogleCodeExporter opened this issue · comments
Google Code Exporter commented
posit: it's probably safe to assume that mailparser will always return the
parts list in order. (1, 1.1, 1.2...)
given that, getMessageBody returns the body of the -last- matching part with
the requested content-type.
this is probably not what most people expect.
even worse, mailparser seems to take a very simple single-part test email i
have, but in addition to the 1.1, text/plain, it has added a 1.2, with zero
length body, and also text/plain for no obvious reason (possible bug in
mailparser? but i'm not an expert on the RFC)
for my own testcase, my single part text-only email, i would have expected
getMessageBody to return the body. instead, it returns an empty string because
part 1.2 is also text/plain, and of length zero.
two possible fixes:
1. have getMessageBody return the first matching part
or
2. ignore any zero length body in the foreach.
for my own use, i did both.
and yes, it is a somewhat fuzzy request, asking for the "message body" from a
multipart message, but these two changes might help.
Original issue reported on code.google.com by benja...@rqdq.com
on 9 Mar 2011 at 9:36
Google Code Exporter commented
In the case where a user sends an email like this:
Hey, look at this funny picture:
[image]
Isn't that duck adorable?
...there will be two text/plain parts which both (arguably, at least) contain
parts of the message body. I dealt with this by changing getMessageBody() to
return the concatenation of all matching parts, although I'm not sure if this
is a reasonable solution. I'm happy to provide a patch if it seems reasonable,
it basically boils down to changing "$body =" to "$body .=" in getMessageBody().
Original comment by epriest...@epriestley.com
on 13 Jun 2011 at 5:07