[ https://issues.apache.org/jira/browse/MIME4J-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12613275#action_12613275 ]
Stefano Bagnara commented on MIME4J-52:
---------------------------------------
For the record the loops also happen with a simplified message:
----
Content-Type: multipart/mixed; boundary="outer-boundary"
Outer preamble
----
So the loop happens when an multipart is declared but it never starts.
The event sequence for this message is:
0 T_START_MESSAGE
3 T_START_HEADER
4 T_FIELD
5 T_END_HEADER
6 T_START_MULTIPART
8 T_PREAMBLE
----- Loop ----
10 T_START_BODYPART
3 T_START_HEADER
- Unexpected end of headers detected. Higher level boundary detected or EOF reached.
- Invalid header encountered
5 T_END_HEADER
12 T_BODY
11 T_END_BODYPART
-2 T_IN_BODYPART (not exposed)
----- End Loop ----
I also found that advancing from T_START_MULTIPART to T_PREABLE makes a call to MimeBoundaryInputStream.skipBoundary with this buffer:
[pos: 0][limit: 16][Outer preamble
]
It happend that MimeStreamParserTest$TestHandler.preamble is called and the first in.read called by the preamble test method (reading the preamble stream) calls the BufferingInputStreamAdaptor.read that in turn calls the MimeBoundaryInputStream.read that at this point already has endOfStream() true and hasData() false.
The bug seems to be there: we have MimeBoundaryInputStream.limit 16 and MimeBoundaryInputStream.buffer.limit 16 so hasData returns false.
ATM I tried changing the hasData from:
return limit > buffer.pos() && limit < buffer.limit();
to
return limit > buffer.pos() && limit <= buffer.limit();
and this seems to fix the issue.
But this is purely TDD because I don't know what I did :-)
I gave a go to the original message you attached but I see the following result
--------
<message>
<header>
<field>
Content-Type: multipart/mixed; boundary="outer-boundary"</field>
</header>
<multipart>
<preamble>
Outer preamble
</preamble>
<body-part>
<header>
<field>
Content-Type: text/plain</field>
</header>
<body>
Foo
</body>
</body-part>
<body-part>
<header>
<field>
Content-Type: multipart/alternative; boundary="inner-boundary"</field>
</header>
<multipart>
<preamble>
AAA
--outer-boundary--
Outer epilouge
</preamble>
<body-part>
<header>
</header>
<body>
</body>
</body-part>
<epilogue>
</epilogue>
</multipart>
</body-part>
<epilogue>
</epilogue>
</multipart>
</message>
-------
And this seems wrong because the outerboundary and the outer epilouge should not be part of the preable.
So there must be something more to fix.
Post by Niklas Therning (JIRA)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.