MultipartForm upload with non ASCII file name

[tim-93]

quarkus:3.15.1
jdk:21

Using the ASCII file name, the file content is normal, and the non-ASCII file name, the file content is null, I don't understand why

`
@post
@consumes(MediaType.MULTIPART_FORM_DATA)
@produces(MediaType.APPLICATION_JSON)
public Response test(@MultipartForm UploadFile uploadFile) {
.....
}

@DaTa
public class UploadFile {

@FormParam("file")
@PartType(MediaType.APPLICATION_OCTET_STREAM)
public InputStream file;
}
`

[gsmet]

I think a small Maven reproducer would be helpful.

[gsmet]

No no, I'm just asking for a reproducer so that we can check what's going on. I added the Maven precision as it's sometimes harder for us to deal with Gradle reproducers.

[tim-93]

Hi，Please refer to me uploaded, thank you!
quakrus-demo.zip

[gsmet]

@dontgm can you clarify how you trigger the issue with your demo so that I can get the exact same problem you are experiencing?

Thanks!

[tim-93]

You need to use a development tool, such as IntelliJ IDEA, import the demo project, and after starting it, use the interface to call the tool, such as Postman, to upload the file request interface. If the file name is ASCII, the interface returns: File is not null!, which is correct. Otherwise, the interface returns: File is null!, which is incorrect.

[harchiki]

Also, one more example of this problem is this issue on stackoverflow : https://stackoverflow.com/questions/78828849/multipartformdatainput-upload-with-non-ascii-file-name-quarkus

i think we all have same problem

[harchiki]

i have same problem. i think somehow fileName* couldnt be parsed in Content-Disposition

i think that causes file body not being find by fileName (it seems encoded properly but its body is set with uncorrect fileName as key in Map)

i couldnt force it to encode properly whatever i ve tried

[tim-93]

I have tried to encode the file name as much as possible, but I didn't expect to find a better solution...

[harchiki]

I have no idea about its solution. I ve debugged its library. Appearantly, it can parse the name in content-disposition. On filename*=UTF-8' 'non-ascii-file-name.pfd, something happens weard. Let's see the response by the reproducer. Otherwise, i will try to consider getting it around somehow