quarkus: Resteasy Reactive Multipart fails if fileName is not set for a file part

Describe the bug

We use resteasy reactive’s multipart to upload a file to our Quarkus (2.3.1.Final) service. This works fine with most clients (e.g. Postman) because they set the filename attribute in the content-disposition.

Unfortunately, one of our clients does not set that and then the upload fails with http error 413 Request Entity Too Large. While debugging, I think I was able to track this down to https://github.com/quarkusio/quarkus/blob/main/independent-projects/resteasy-reactive/server/runtime/src/main/java/org/jboss/resteasy/reactive/server/core/multipart/MultiPartParserDefinition.java#L237 . In this line, it is checked if the content-disposition header contains the filename part. Only if the filename is there, the content is assumed to be a file.

Therefore, in our case, resteasy reactive thinks the content cannot be a file and thus continous to read the content as an attribute and thus fails when the attribute becomes too large (https://github.com/quarkusio/quarkus/blob/main/independent-projects/resteasy-reactive/server/runtime/src/main/java/org/jboss/resteasy/reactive/server/core/multipart/MultiPartParserDefinition.java#L292).

Since the filename is only an optional part of a file upload, I think resteasy reactive should not depend on it. Probably it would be better to check the content type to see if it is something like application/octet-stream or an image or so.

Expected behavior

The upload works as expected.

Actual behavior

The upload fails with a 413 error because the file upload is misinterpreted.

How to Reproduce?

I wasn’t able to reproduce the missing filename with curl or postman. The client that did not send the request was a flutter app. So I cannot easily provide a reproducer.

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 24 (22 by maintainers)

Commits related to this issue

Most upvoted comments

Well, the RFC states that it is allowed to omit the filename:

   ... The file name isn't mandatory
   for cases where the file name isn't available or is meaningless or
   private; this might result, for example, when selection or drag-and-
   drop is used or when the form data content is streamed directly from
   a device. ...

https://datatracker.ietf.org/doc/html/rfc7578#section-4.2

In our case, the file name is also meaningless. As a workaround, we now just specify some dummy value that we ignore on the server side.

+2
andreas-eberle on Oct 21, 2021

Users don’t have to do anything.

If you use one of the supported file types, then RR will always save the contents of that part of the multipart request as a file

+1
geoand on Dec 7, 2022
Read more comments on GitHub
← quarkus: Resteasy Reactive first POST with InputStream hang
quarkus: RESTEasy Reactive: NPE due to some exceptions →