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

Reply via email to