[
https://issues.apache.org/jira/browse/MIME4J-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17987953#comment-17987953
]
Gregory Lepore edited comment on MIME4J-332 at 7/2/25 5:51 PM:
---------------------------------------------------------------
RFC 6266 ([https://httpwg.org/specs/rfc6266.html]), which discusses Use of the
Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) says
"Therefore, when both "filename" and "filename*" are present in a single header
field value, recipients _SHOULD_ pick "filename*" and ignore "filename"".
It also has an appendix covering this:
h2. [Appendix
D.|https://httpwg.org/specs/rfc6266.html?utm_source=chatgpt.com#rfc.section.D]
[Advice on Generating Content-Disposition Header
Fields|https://httpwg.org/specs/rfc6266.html?utm_source=chatgpt.com#advice.generating]
To successfully interoperate with existing and future user agents, senders of
the Content-Disposition header field are advised to:
* Include a "filename" parameter when US-ASCII
([??[US-ASCII]??|https://httpwg.org/specs/rfc6266.html?utm_source=chatgpt.com#US-ASCII])
is sufficiently expressive.
* Use the 'token' form of the filename parameter only when it does not contain
disallowed characters (e.g., spaces); in such cases, the quoted-string form
should be used.
* Avoid including the percent character followed by two hexadecimal characters
(e.g., %A9) in the filename parameter, since some existing implementations
consider it to be an escape character, while others will pass it through
unchanged.
* Avoid including the "\" character in the quoted-string form of the filename
parameter, as escaping is not implemented by some user agents, and "\" can be
considered an illegal path character.
* Avoid using non-ASCII characters in the filename parameter. Although most
existing implementations will decode them as ISO-8859-1, some will apply
heuristics to detect UTF-8, and thus might fail on certain names.
* Include a "filename*" parameter where the desired filename cannot be
expressed faithfully using the "filename" form. Note that legacy user agents
will not process this, and will fall back to using the "filename" parameter's
content.
* When a "filename*" parameter is sent, to also generate a "filename"
parameter as a fallback for user agents that do not support the "filename*"
form, if possible. This can be done by substituting characters with US-ASCII
sequences (e.g., Unicode character point U+00E4 (LATIN SMALL LETTER A WITH
DIARESIS) by "ae"). Note that this may not be possible in some locales.
* When a "filename" parameter is included as a fallback (as per above),
"filename" should occur first, due to parsing problems in some existing
implementations.
* Use UTF-8 as the encoding of the "filename*" parameter, when present,
because at least one existing implementation only implements that encoding.
was (Author: g...@rhobard.com):
RFC 6266 (https://httpwg.org/specs/rfc6266.html), which discusses Use of the
Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) says
"Therefore, when both "filename" and "filename*" are present in a single header
field value, recipients _SHOULD_ pick "filename*" and ignore "filename"".
> 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)
