[ 
https://issues.apache.org/jira/browse/MIME4J-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17987955#comment-17987955
 ] 

Gregory Lepore commented on MIME4J-332:
---------------------------------------

Unfortunately there is no solid, complete .eml specification, it's a cobbled 
together bunch of stuff. 6266 isn't directly applicable, but it does handle the 
duplicate filename issue and gives a reasonable solution. Email specs in 
general are ugly. I doubt we'll find anything definitive, and I'd be happy with 
either/or as opposed to both.

> Prevent concatenation of duplicate fields in ContentDispositionParser
> ---------------------------------------------------------------------
>
>                 Key: MIME4J-332
>                 URL: https://issues.apache.org/jira/browse/MIME4J-332
>             Project: James Mime4j
>          Issue Type: Task
>            Reporter: Tim Allison
>            Priority: Minor
>
> Over on https://issues.apache.org/jira/browse/TIKA-4447, [~g...@rhobard.com] 
> reported that content disposition fields were concatenating file names if 
> there were multiple file names.
> Minimal reproducer in {{master}} in {{{}ContentDispositionTest{}}}:
> {code:java}
> @Test
> public void testDuplicateFields() throws ParseException { 
>   String s = "attachment; filename=\"bar1.rtf\"; filename=\"bar2.rtf\"; 
> filename=\"bar3.rtf\"";
>   ContentDispositionParser parser = new ContentDispositionParser(new 
> StringReader(s));
>   parser.parse(); 
>   assertEquals("bar1.rtf", parser.getParameters().get("filename")); 
> }
>  
> {code}
> With result:
> {noformat}
> org.junit.ComparisonFailure: 
> Expected :bar1.rtf
> Actual   :bar1.rtfbar2.rtfbar3.rtf
>   {noformat}
> I'm not sure whether the "correct" behavior is to pick the first or the last. 
> It looks like Thunderbird picks the first.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to