-
Type: Improvement
-
Status: Resolved
-
Priority: Minor
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 2025.x
-
Component/s: Automation, WebEngine
-
Release Notes Description:
-
Epic Link:
-
Tags:
-
Team:PLATFORM
-
Sprint:nxplatform #114, nxplatform #115
-
Story Points:2
We parse MultiPart request in 2 different ways:
- In Automation, it uses MultiPartRequestReader and MultiPartFormRequestReader classes, which use javax.mail.*.
- In Batch Upload (and WebEngine), it uses FormData, which use Apache Commons Fileupload.
We have an issue on the filename, when it contains other characters than the one in US-ASCII.
Commons Fileupload reads correctly encoded filename in the header, as it uses UTF-8 encoding by default.
However, javax.mail seems to fail at it, it cannot decode correctly the filename. To make it correctly decode the filename, we should use filename*=UTF-8'' in the part header:
...
form-data; name="file"; filename*=UTF-8''blablaéèôûü__.txt
...
Browsers (at least Chrome and Firefox) send only filename in the part header:
... form-data; name="file"; filename="blablaéèôûü__.txt" ...
=> We should probably align all the code to use Apache Commons Fileupload to parse MultiPart requests, and make sure we send correctly encoded part headers.
We also generate MultiPart response with javax.mail.*, since NXP-32651 we have a configuration property to switch the generation mechanism to Jersey.
=> We should remove all MultiPart generation using javax.mail.* and make the Jersey mechanism the default and only one.
- is related to
-
NXP-32651 Return the Content-Disposition multipart header in UTF8 encoding
- Resolved