Niklas Therning ha scritto:
Stefano Bagnara wrote:
Niklas submitted this message as part of MIME4J-52
==========================
Content-Type: multipart/mixed; boundary="outer-boundary"
Outer preamble
--outer-boundary
Content-Type: text/plain
Foo
--outer-boundary
Content-Type: multipart/alternative; boundary="inner-boundary"
AAA
--outer-boundary--
Outer epilouge
============================
What is the expected result for this?
Should the parser understand that the inner multipart never starts and
that it instead find another outer boundary?
ATM mime4j locks in a loop.
Adding the fix I proposed in a comment to that issue the result is
that mime4j consider:
=============================
AAA
--outer-boundary--
Outer epilouge
=============================
the preamble of the inner multipart ignoring the "--outer-boundary--"
of the external multipart.
What is the correct/best way to handle bad multiparts like this?
With the old version of Mime4j the result would be:
===============================
AAA
===============================
this would be reported as the inner multipart's preamble while
===============================
Outer epilogue
===============================
would reported as the outer multipart's epilogue.
Furthermore, IIRC, the old Mime4j would report an empty bodypart and
empty epilogue for the inner multipart. I think this is a nice feature
since the events generated by Mime4j would always represent a valid MIME
message even if the input isn't entirely valid.
I think that what you reported is also what the RFC mandates, so we
should really revert to that behaviour.
I just tested the result of nesting of MimeBoundaryInputStream I tried
locally (referred in MIME4J-52) and it is equivalent to what you reported.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
