[
https://issues.apache.org/jira/browse/MIME4J-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020994#comment-13020994
]
Oleg Kalnichevski commented on MIME4J-194:
------------------------------------------
> That said I think this behaviour shows another issue with input files having
> weird Content-Types: if you parse a message having
> Content-Type: multipart/mixed and no boundary parameter it seems that mime4j
> doesn't complaint about it while parsing but build
> a bad object that will fail when written by the MimeWriter: am I right?
The low MIME parser always uses RawFieldParser to extract content-type, charset
and boundary bits. RawFieldParser can handle empty parameters and other minor
malformations just fine. The problem is when DOM is used some fields currently
get parsed twice (once by CORE and once by DOM). See MIME4J-116. I am currently
looking into ways of fixing it for 0.7.
As far as RawFieldParser in CORE is concerned I can make it behave differently
in strict vs lenient mode. I do not think there is much we can do about
ContentTypeFieldImpl and friends in DOM without solving MIME4J-172 first.
Oleg
> ContentTypeFieldImpl (and possibly other parsers in DOM) is unable to handle
> empty parameters ";;"
> --------------------------------------------------------------------------------------------------
>
> Key: MIME4J-194
> URL: https://issues.apache.org/jira/browse/MIME4J-194
> Project: JAMES Mime4j
> Issue Type: Bug
> Components: dom
> Affects Versions: 0.6.1, 0.7
> Reporter: Stefano Bagnara
> Fix For: 0.8
>
> Attachments: contenttypeemptyparameters.msg
>
>
> I guess this is a regression introduced with MIME4J-145.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
