james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (JIRA)" <mime4j-...@james.apache.org>
Subject [jira] Commented: (MIME4J-180) exception expected when mime part has no end boundary and parsing is strict
Date Wed, 10 Nov 2010 14:59:13 GMT

    [ https://issues.apache.org/jira/browse/MIME4J-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12930616#action_12930616
] 

Oleg Kalnichevski commented on MIME4J-180:
------------------------------------------

Rohan

There is a slight problem. Let me try to explain. The mime4j parser maintains a number of
internal read-ahead buffers for performance reasons. Often, when parsing a fairly small message
(such as the one you have used in the test case) the entire body part ends up read until the
end of the boundary early in the process (while still parsing the fields in the header). The
upshot of this is that the exception can be thrown by the parser#next() method and not while
reading from the input stream returned by parser#getInputStream(). If you can live with this
limitation the fix for the problem should be relatively easy. If not, the state of the parser
will have to be propagated to the lower level components through an ugly hack of some sort,
which is something I would really hate to do.

Oleg

> exception expected when mime part has no end boundary and parsing is strict
> ---------------------------------------------------------------------------
>
>                 Key: MIME4J-180
>                 URL: https://issues.apache.org/jira/browse/MIME4J-180
>             Project: JAMES Mime4j
>          Issue Type: Improvement
>    Affects Versions: 0.6
>            Reporter: Rohan Hart
>            Priority: Minor
>             Fix For: 0.7
>
>         Attachments: TuncTest.java
>
>
> It would simplify my code if, when parsing strictly, the body text stream provided by
a mime part would throw an exception, eg., EOFException, when the part has no end boundary.
 This seems semantically more correct.
> The current behaviour means that I can't just pass the stream but have to wrap it in
a proxy which knows about the real stream, the original mime parser and the sequence of events
which lead to a check for the end of boundary.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message