-
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 form improvement #22205
Comments
/cc @geoand, @stuartwdouglas |
Actually, ideally I'd have multipart be transparent entirely, allowing it just as we allow form parameters: @POST
public void post(@RestHeader String contentType,
@RestForm String param,
@RestForm File file,
@RestForm FileUpload otherFile){} As well as on public static class Params {
@RestHeader String contentType;
@RestForm String param;
@RestForm File file;
@RestForm FileUpload otherFile;
}
@POST
public void post(@BeanParam Params all){} And also, why are the |
Yeah, we should probably merge the code of the two |
So, I vote for the following changes:
WDYT @geoand ? |
WDYM by this?
Are you sure this is enough to differentiate them? The rest sounds reasonable to me |
I mean |
Did you see https://jakarta.ee/specifications/restful-ws/3.1/jakarta-restful-ws-spec-3.1.html#consuming_multipart_formdata BTW? There's support for multipart now upstream. But only for |
LOL |
So, I'm looking into this. It's really a pity those two things diverged so much. It appears that regular form elements sent via multipart will have a mime type The big differences that I've noted between
BTW, I find it a bit confusing that for |
Maaaan, this code has changed a lot since the last time I looked at it :( |
One thing I can't quite figure out yet is why some fields are annotated with In fact, I don't know what that annotation is for. The javadocs say:
The documentation says:
And I'm left wondering what it's for. Because multipart elements actually come with their mime types set, like |
I am pretty sure we are. |
I can't see where. |
I am making good progress allowing multipart parameters already. |
I can see why you didn't add support for parameters, man. It's like fitting a square peg in a round hole! |
I honestly don't remember 😂 |
Maybe I remember something else... |
Huh, I also suspect that one of the reason you didn't add support for multipart in |
Very likely |
Oh, I can't blame you. This is why I love ASM:
Translation: you're screwed, man, give up. |
Yeah, I stay as far away from it as I can 😅 |
First test passed, with the BeanParam generator! Turns out I forgot to |
🎉 |
Oh FFS. This took hours to find:
Apparently when type is |
PFEW. OK, the version with message body readers also passes now. Just in time to go on PTO with working code, and later come back and do a PR. |
Thanks for your perseverance! |
Pffff, now it looks like I broke the rest client. |
Grrrr, it looks like the types supported by the server and client for multipart don't match :( |
Client appears to support:
|
Also, it appears there are code paths in the client that invoke the converter for form params, but others not. I don't know why yet. |
It doesn't look like the client really supports generic types wrt. multipart and message body writers, and it doesn't seem to have any default or generated On the bright side, it appears the client tests pass. So, done:
Todo:
We are getting closer, though. |
Just when I thought I was done, I learned we have a vertx runtime for RESTEasy Reactive, without Quarkus. Huh. |
This is the issue that keeps on giving. |
The motherload of rabbit holes. |
|
Finally, it's all there: #27526 |
Cool! I'll have a look next week. |
Thanks :) |
I believe the UX is much simpler for users now, and we have a single code-base to maintain for containing classes, though sadly it's in ASM rather than gizmo, but we can always later decide to convert it to gizmo as long as we keep a single generator, so there's always hope. |
- Merged support into @BeanParam handling - Deprecated @MultipartForm - Auto-detect @BeanParam classes, annotation now optional - Use ParamConverter instead of MessageBodyReader for plain text multiparts - Auto-default to Accept: urlencoded or multipart depending on types of @FormParam present - Support multipart form elements as endpoint parameters and fields - Breaking: need @restform(FileUpload.ALL) for getting all uploads
- Merged support into @BeanParam handling - Deprecated @MultipartForm - Auto-detect @BeanParam classes, annotation now optional - Use ParamConverter instead of MessageBodyReader for plain text multiparts - Auto-default to Accept: urlencoded or multipart depending on types of @FormParam present - Support multipart form elements as endpoint parameters and fields - Breaking: need @restform(FileUpload.ALL) for getting all uploads
- Merged support into @BeanParam handling - Deprecated @MultipartForm - Auto-detect @BeanParam classes, annotation now optional - Use ParamConverter instead of MessageBodyReader for plain text multiparts - Auto-default to Accept: urlencoded or multipart depending on types of @FormParam present - Support multipart form elements as endpoint parameters and fields - Breaking: need @restform(FileUpload.ALL) for getting all uploads
deprecated by quarkusio/quarkus#22205 (cherry picked from commit a3d897a)
deprecated by quarkusio/quarkus#22205 (cherry picked from commit a3d897a)
Description
ATM, we only support
@RestForm File
when they're in a class along with@Consumes(MediaType.MULTIPART_FORM_DATA)
to trigger the special handling, forcing me to write code like this:Initially I had this:
But it did not work. Apparently
@FormParam File
can only happen in a wrapper class, but while it's fine that there's an option to do this, I'd very much like to be able to do the same on parameters.Also, the docs at https://quarkus.io/guides/resteasy-reactive#handling-multipart-form-data tell me I can write:
And that:
But I don't even see why we require
@Consumes(MediaType.MULTIPART_FORM_DATA)
to trigger form loading. We don't need such a marker for regular url-encoded forms, do we? IMO we can infer that we're going to have to do form loading at build time by just finding@RestForm
or@MultipartForm
parameters.Once we know it's a form, we can check the content-type at runtime to turn on url-encoded or multipart unserialising, no?
BTW
@MultipartForm
is actually only required because of JAX-RS treating unannotated params as the body, but I think we could go and scan the damn type and if there are@RestForm
fields in there not treat it as a body but infer@MultipartForm
behaviour.Implementation ideas
No response
The text was updated successfully, but these errors were encountered: