james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefano Bagnara (JIRA)" <mime4j-...@james.apache.org>
Subject [jira] Resolved: (MIME4J-153) Headless inconsistency between MimeTokenStream and MimeStreamParser
Date Sat, 24 Apr 2010 19:45:51 GMT

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

View raw message