[
https://issues.apache.org/jira/browse/MIME4J-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefano Bagnara resolved MIME4J-153.
------------------------------------
Resolution: Fixed
So, I went for the (c) solution (simply because it was the easier one) in
MimeTokenStream by simply invoking next() once in doParse while starting an
headless parse (so that from T_END_HEADER we go to the appropriate T_*_BODY
event). I'm not agains moving to (a) if we later think it is more appropriate.
I also changed the MimeStreamParser headless parsing to use tokenstream
headless parsing instead of building a full message by synthetizing a fake
header stream. Now it synthetizes the header event calls, instead, and then
continue with the old event handling.
> Headless inconsistency between MimeTokenStream and MimeStreamParser
> -------------------------------------------------------------------
>
> Key: MIME4J-153
> URL: https://issues.apache.org/jira/browse/MIME4J-153
> Project: JAMES Mime4j
> Issue Type: Bug
> Affects Versions: 0.6
> Reporter: Stefano Bagnara
> Assignee: Stefano Bagnara
> Priority: Minor
> Fix For: 0.7
>
>
> Weird things are:
> - We have 2 separate code to handle headless messages in the 2 type of
> parsers (MimeStreamParser does not rely on the MimeTokenStream solution).
> - MimeTokenStream headless parsing is done so to start the parsing and the
> state events from "MimeTokenStream.T_END_HEADER": I think this is unexpected
> and either it should alternatively:
> a) "simulate" all of the events (starting from T_START_MESSAGE... and
> simulating a full event stream for an header with only the supplied
> content-type)
> b) return only from START_MULTIPART to END_MULTIPART (or simply T_BODY if
> the content-type was not a multipart), but not return a T_END_MESSAGE as it
> never returned a T_START_MESSAGE.
> c) return all of the events as if it was interrupted after the header, so
> starting from START_MULTIPART / T_BODY through all of the events including
> T_END_MESSAGE/T_END_OF_STREAM until it consumed all of the stream.
> I've a small preference for a and c because b doesn't seem to be feasible
> (currently the parser does not stop in the last boundary but includes all of
> the content after the last boundary in the epilogue, so you can't really use
> the headless mode to run partial parsing if you don't have a limited stream).
> Clearly the current way (starting from T_END_HEADER) seems the worst one.
> - MimeStreamParser instead simulate the headless parsing by simply prepending
> a fake header including an artificial content-type based on the supplied
> contentType
> - In both cases it is not clear, in the contract, what kind of
> encoding/wrapping is done/expected on the "contenttype" parameter.
> Related: http://issues.apache.org/jira/browse/MIME4J-128
> I have a question: what are the use-cases for the 2 current headless parsing?
> I'd like to better understand them so to be able to choose the best "fix" for
> this issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
