arturobernalg commented on PR #618:
URL:
https://github.com/apache/httpcomponents-client/pull/618#issuecomment-3061728798
> Question: Wouldn't it be more standard compliant to render the filename*
attribute whenever the string is not US-ASCII encodable? E.g., Embedded Tomcat
10.1 does not properly parse the ISO-8859-1 filename content, but correctly
handles filename*. It seems to me that the default ISO-8859-1 assumption,
although mentioned in some RFCs, is not consistently true in reality.
RFC 7578 §4.2 is crystal clear:
**NOTE: The encoding method described in RFC 5987, which would add a
filename* parameter to the Content-Disposition header field, MUST NOT be used.**
HttpClient 5.5 therefore emits filename* only when the filename contains
code points that ISO-8859-1 cannot represent. Everything in the 0x00-0xFF range
already has a legal encoding, so adding filename* there would break the letter
of the spec and has no real-world upside.
If embedded Tomcat 10.1 stumbles over an ISO-8859-1 filename, that is a
Tomcat issue, not a protocol requirement. Use HttpMultipartMode.EXTENDED
(percent-encoded names) as a workaround or open a bug with Tomcat, but let’s
keep HttpClient on the right side of the standards
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
