[
https://issues.apache.org/jira/browse/MIME4J-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niklas Therning closed MIME4J-47.
---------------------------------
> Nested multipart messages with non-empty epilogue cause indefinite loop
> -----------------------------------------------------------------------
>
> Key: MIME4J-47
> URL: https://issues.apache.org/jira/browse/MIME4J-47
> Project: Mime4j
> Issue Type: Bug
> Affects Versions: 0.4
> Reporter: Niklas Therning
> Assignee: Niklas Therning
> Fix For: 0.4
>
> Attachments: 36368753.msg, mime4j.patch
>
>
> I'm attaching a very simple message which causes the current version of
> Mime4j to loop indefinitely when the following app is run:
> public static void main(String[] args) throws IOException {
> String msg = "36368753.msg";
> MimeTokenStream stream = new MimeTokenStream();
> stream.parse(new FileInputStream(msg));
>
> while (stream.getState() != EntityStates.T_END_OF_STREAM) {
> stream.next();
> }
> }
> If the line 'foo' is removed completely the message will parse as expected.
> I've tried to figure out why this happens. It seems like the
> MimeBoundaryInputStream becomes out of sync for the outer multipart at the
> end. The skipBoundary() method is called when read() is invoked even though
> we're not at the boundary yet which means that the end boundary won't be
> detected properly. One observation I did is that reset() doesn't set eof to
> false. If I do that in reset() the mail parses as expected:
> public void reset() {
> atBoundary = false;
> limit = -1;
> eof = false;
> }
> I could check in this fix myself but I do not know enough about the recent
> changes in Mime4j to be able to determine if this is the correct way to fix
> this problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
