-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Resteasy Reactive Multipart fails if fileName is not set for a file part #20938
Comments
/cc @FroMage, @geoand, @stuartwdouglas |
The failing request looks like this:
A working request (from Postman) looks like this:
So the only real difference is the |
To be honest, I am not in favor of fixing this as it's clearly a case of a problematic client request. @stuartwdouglas WDYT? |
Well, the RFC states that it is allowed to omit the filename:
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. |
The thing is that when |
Why do you think so? Couldn't you use the content type to determine this? You could write the stream to disk, when the content type of a part is application/octet-stream or something like this (e.g. jpeg etc.). |
That sounds like a hack TBH |
Why do you think so? I mean the content type specifies what is in the field. To me the filename check looks more like a hack. That fields does not have to be there. But the content type has to be specified and specifies what the actual type of the field is. |
So we could kinda make this work by looking at the content type, as if it is anything other than 'text/plain' (the default) we could likely assume it was a file, however uploading text files would still fail. I guess we could attempt to somehow explicitly tell the parser which fields are files based on the name. |
What if you combine both ideas? I mean in the case there is a filename, go with it and handle it like you do at the moment. And if there is no filename but the content type is binary (octet-stream, image, ...), also handle it like a file. What do you think about that? |
I think if we are going to fix this it needs to be done via the application somehow notify the parser that a given field is a file, anything else will be somewhat hacky and have the potential to cause other problems. |
I have the same issue in one of our apps, and it's really the only thing blocking from switching over to reactive (it works today using classic resteasy multipart). Since our application already specify the multipart field as type FileUpload, there should be enough information 🤔
|
I've just ran into this as well. In my case I can control the client; however can't Quarkus just store stuff in a file any time the consuming method uses a |
In Keycloak, we are also facing the same issue. For us, it will be a breaking change (and as mentioned before, not 100% aligned with the specs) if we start forcing the In our case, the file name is also meaningless. |
I will have another look tomorrow |
This seems like the most robust approach, so I'll look into it |
This does seem to work, I'll clean up what I have and open a PR tomorrow |
…ts it With this change, if the JAX-RS endpoint expects a multipart request to contain a file, then that file is always written to disk regardless of whether the content-disposition contains the filename attribute of not. Fixes: quarkusio#20938
#29716 takes care of the issue |
…ts it With this change, if the JAX-RS endpoint expects a multipart request to contain a file, then that file is always written to disk regardless of whether the content-disposition contains the filename attribute of not. Fixes: quarkusio#20938
Thanks! |
🙏🏼 |
@geoand : Thanks for the fix! Can you explain what we have to do in the future? Do we need a new annotation? |
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 |
That's great news! Thanks a lot for providing this fix! |
🙏 |
…ts it With this change, if the JAX-RS endpoint expects a multipart request to contain a file, then that file is always written to disk regardless of whether the content-disposition contains the filename attribute of not. Fixes: quarkusio#20938
Ensure that file is written on disk for multipart when endpoint expects it
…ts it With this change, if the JAX-RS endpoint expects a multipart request to contain a file, then that file is always written to disk regardless of whether the content-disposition contains the filename attribute of not. Fixes: quarkusio#20938
…ts it With this change, if the JAX-RS endpoint expects a multipart request to contain a file, then that file is always written to disk regardless of whether the content-disposition contains the filename attribute of not. Fixes: quarkusio#20938 (cherry picked from commit ec2a4a4)
…ts it With this change, if the JAX-RS endpoint expects a multipart request to contain a file, then that file is always written to disk regardless of whether the content-disposition contains the filename attribute of not. Fixes: quarkusio#20938 (cherry picked from commit ec2a4a4)
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 thecontent-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 thefilename
part. Only if thefilename
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 likeapplication/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
orver
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
orgradlew --version
)No response
Additional information
No response
The text was updated successfully, but these errors were encountered: