[
https://issues.apache.org/jira/browse/MIME4J-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joshua Turner updated MIME4J-284:
---------------------------------
Affects Version/s: 0.7.2
Description:
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.
Component/s: parser (core)
Summary: Headers are being unfolded incorrectly if they contain
an equals sign (was: "Reference:" headers are being split in unintended places)
> 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
>
> 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
(v7.6.3#76005)
