[
https://issues.apache.org/jira/browse/MIME4J-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17842915#comment-17842915
]
Benoit Tellier commented on MIME4J-284:
---------------------------------------
https://github.com/apache/james-mime4j/pull/105 proves that this is no longer
the case in MIME4J 0.8.x ?
> Headers are being unfolded incorrectly if they contain an equals sign
> ---------------------------------------------------------------------
>
> Key: MIME4J-284
> URL: https://issues.apache.org/jira/browse/MIME4J-284
> Project: James Mime4j
> Issue Type: Bug
> Components: parser (core)
> Affects Versions: 0.7.2
> Reporter: Joshua Turner
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Given a set of headers like the following:
> {noformat}
> MIME-Version: 1.0
> References:
> <CAMpLFpB=uu_mqgwf5rtowqcfkd9cmzkboj782872ydgfp1d...@mail.gmail.com>
> <CAMpLFpCVygEwb+t=FmD6TqiDLrQHkREvh=_2=zinf8wh1-y...@mail.gmail.com>
> In-Reply-To:
> <CAMpLFpCVygEwb+t=FmD6TqiDLrQHkREvh=_2=zinf8wh1-y...@mail.gmail.com>{noformat}
> The equals sign in the second reference is causing Mime4J to recognize the
> second line as a new Field, with the first part of the 2nd message id as the
> key, and the part after the equals sign as the value. I'm reasonably sure
> that this is happening in
> org.apache.james.mime4j.stream.RawFieldParser.parseParameter(), when calling
> parseToken() – as the cursor loops over the input byte sequence, whitespace
> at the beginning of the line is ignored in the consideration of whether the
> given line represents a new K-V pair, or a folded continuation of the
> preceding one.
> See RFC2822 Sec 2.2.3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
