[
https://issues.apache.org/jira/browse/MIME4J-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12613389#action_12613389
]
Stefano Bagnara commented on MIME4J-52:
---------------------------------------
I think I found a solution by using nested
"MimeBoundaryInputStream-InputBuffer" tuples instead of recreating
MimeBoundaryInputStream always from the root buffer.
This also involve many other changes (remove the use of InputStream+InputBuffer
in favor of the single InputBuffer), so I will cleanup things and create a
branch to show the solution to allow outer boundary to keep checking the stream
on higher priority.
> Infinite loop when nested multipart is missing end boundary
> -----------------------------------------------------------
>
> Key: MIME4J-52
> URL: https://issues.apache.org/jira/browse/MIME4J-52
> Project: Mime4j
> Issue Type: Bug
> Affects Versions: 0.4
> Reporter: Niklas Therning
> Fix For: 0.4
>
> Attachments: 36387089_3.msg
>
>
> I'm attaching a message which causes Mime4j to loop indefinitely in
> non-strict mode. The message contains badly formatted MIME. The inner
> multipart has no end boundary. Mime4j 0.3 handled this situation without any
> problems. The inner multipart would stop at --outer boundary-- and the AAA
> would be part of the preamble for the inner multipart.
--
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]
