[jira] Resolved: (MIME4J-153) Headless inconsistency between MimeTokenStream and MimeStreamParser

["Stefano Bagnara (JIRA)" <mi...@james.apache.org>]

     [ 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.