quarkusio / quarkus

Quarkus: Supersonic Subatomic Java.
https://quarkus.io
Apache License 2.0
13.64k stars 2.64k forks source link

quarkus.http.body.uploads-directory is ignored when storing binary of REST request input #18113

Open iompo opened 3 years ago

iompo commented 3 years ago

I have a REST endpoint that receives a multipart containing a file. I tried to define a custom temporary folder where to store that file, using the property quarkus.http.body-handler.uploads-directory. When the server receives the rest request the file contained in the multipart is stored in the file system temp folder and not in the one specified by the property. This is my REST endpoint:

    @POST
    @Consumes(MULTIPART_FORM_DATA)
    public String uploadFile(@MultipartForm BinaryRequestBody binary) throws IOException {
    ....
    }

the multipart BinaryRequestBody:

public class BinaryRequestBody {

    @FormParam("file")
    @PartType(APPLICATION_OCTET_STREAM)
    public File file;

    @FormParam("fileName")
    @PartType(TEXT_PLAIN)
    public String fileName;
}

and the application.properties:

quarkus.http.body.handle-file-uploads = true
quarkus.http.body-handler.uploads-directory = /home/tempFolder
quarkus.http.body.preallocate-body-buffer = true
quarkus.http.body.delete-uploaded-files-on-end = false

Expected behavior

The file contained in the BinaryRequestBody object should be stored into /home/tempFolder

Actual behavior

The file contained in the BinaryRequestBody is stored in the default temp directory

Quarkus version or git rev

1.13.7.Final

Build tool

Gradle 6.8.3 Kotlin: 1.4.20 Groovy: 2.5.12 JVM: 11.0.10 (AdoptOpenJDK 11.0.10+9) OS: Mac OS X 10.16 x86_64

quarkus-bot[bot] commented 3 years ago

/cc @evanchooly

geoand commented 3 years ago

Thanks for reporting!

Can you please share a reproducer project?

iompo commented 3 years ago

Hi geoand, here the link to a reproducer project.

geoand commented 3 years ago

Thanks.

It appears that RESTEasy Classic does not write the content of the multipart request to the file system, but leaves that task to the user. Is that correct @ronsigal ?

belkevglaz commented 3 years ago

Have the same problem. How to get this work ?

geoand commented 3 years ago

It doesn't work at the moment

geoand commented 1 year ago

cc @jamezp

jamezp commented 1 year ago

I assume the goal here is to write data to a file. Currently RESTEasy uses Apache mime4j to process multipart data. It uses a ThresholdStorageProvider which stores data in memory if it's small enough, defaults to 1024 bytes. If that is surpassed then the data will be written to a file. However, it does look like there currently isn't a way to define where the temporary file is created. Is this what we're after here?

geoand commented 1 year ago

Exactly

jamezp commented 1 year ago

Okay. We've got some changes coming up along these lines. We could add this too. However, the 4.7.x branch really isn't getting more features. We could consider it for 5.x, but RESTEasy has moved past Jakarta REST 2.1 to Jakarta REST 3.1 and eventually 4.0.

geoand commented 1 year ago

Understood, thanks

geoand commented 1 week ago

Has this perhaps been fixed with the latest versions of RESTEasy?

jamezp commented 1 week ago

@geoand I apologize it looks like this never got looked at. I've filed https://issues.redhat.com/browse/RESTEASY-3542 for this. Currently everything just uses the java.io.tmpdir.

geoand commented 1 week ago

🙏🏽