You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Niklas Therning (JIRA)" <se...@james.apache.org> on 2008/07/10 21:38:33 UTC

[jira] Resolved: (MIME4J-47) Nested multipart messages with non-empty epilogue cause indefinite loop

     [ https://issues.apache.org/jira/browse/MIME4J-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Niklas Therning resolved MIME4J-47.
-----------------------------------

       Resolution: Fixed
    Fix Version/s: 0.4

Thanks Oleg, your patch has been applied.

> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org