[
https://issues.apache.org/jira/browse/FILEUPLOAD-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated FILEUPLOAD-362:
---------------------------------------
Assignee: Gary D. Gregory
> Unable to parse requests for file uploads with special characters in filename
> on Windows
> ----------------------------------------------------------------------------------------
>
> Key: FILEUPLOAD-362
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-362
> Project: Commons FileUpload
> Issue Type: Bug
> Affects Versions: 2.0.0-M1
> Reporter: Kusal Kithul-Godage
> Assignee: Gary D. Gregory
> Priority: Major
>
> [This
> commit|https://github.com/apache/commons-fileupload/commit/63e243fe8ded60a5d40659db8226a9f5ea43fd88#diff-96321c47e1a58f258784f31b899d0ae2789fb234197b65f92032fca540762aeaR111]
> introduced an additional {{Paths#get}} call during file name validation.
> Previously, it only checked for NUL characters, but now it also checks that
> the filename is valid for the OS that the Java application is running on.
> This means a web server running on Windows is unable to accept file uploads
> where the original filename has special characters (e.g. from Unix-based
> clients where it is valid).
> As far as I know, the multipart field's filename value is simply informative
> and isn't used to actually write a file to disk - and so there shouldn't be
> any need for commons-fileupload to check it is a valid filename on the server
> OS (and in any case, it should not forcibly reject it). Any OS-specific
> implications of the original filename should be the consuming code's
> responsibility.
> I'm not aware of any way to disable or override this new validation
> behaviour. The JavaDoc for
> {{org.apache.commons.fileupload2.core.DiskFileItem#getName}} suggests
> catching the {{InvalidPathException}} to retrieve the original filename if
> desired; however, this is not practical in the scenario where
> {{org.apache.commons.fileupload2.core.AbstractFileUpload#parseRequest}} is
> being called and the exception is thrown within its calling code.
> Sample request for reproduction (server should be running on Windows):
> {code:java}
> curl -X POST "http://localhost/endpoint"; -F
> "file=content;filename=file?name.txt;type=text/plain"{code}
> Stack trace:
> {code:java}
> java.nio.file.InvalidPathException: Illegal char <?> at index 4: file?name.txt
> at
> java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:204)
> at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:175)
> at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
> at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
> at
> java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:231)
> at java.base/java.nio.file.Path.of(Path.java:148)
> at java.base/java.nio.file.Paths.get(Paths.java:69)
> at
> org.apache.commons.fileupload2.core.DiskFileItem.checkFileName(DiskFileItem.java:166)
> at
> org.apache.commons.fileupload2.core.FileItemInputImpl.getName(FileItemInputImpl.java:183)
> at
> org.apache.commons.fileupload2.core.AbstractFileUpload.lambda$parseRequest$1(AbstractFileUpload.java:478)
> at
> org.apache.commons.io.function.IOIterator.forEachRemaining(IOIterator.java:77)
> at
> org.apache.commons.fileupload2.core.AbstractFileUpload.parseRequest(AbstractFileUpload.java:467)
> at
> org.apache.commons.fileupload2.jakarta.servlet6.JakartaServletFileUpload.parseRequest(JakartaServletFileUpload.java:116){code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
