Multipart upload in subresource fails in quarkus-rest.

[bjornpalmqvist]

Describe the bug

When using subresources multipart upload fails with 415, Unsupported Media Type, as http error code.

Expected behavior

File upload works as expected.

Actual behavior

Getting 415, Unsupported Media Type, http status.

How to Reproduce?

Make a main resource and have it expose a subresource that consumes multipart/form-data.

See code-with-quarkus.zip example that reproduces the problem.

Output of uname -a or ver

Linux LAPTOP-2P262G2R 5.15.167.4-microsoft-standard-WSL2 #1 SMP Tue Nov 5 00:21:55 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Output of java -version

openjdk 21.0.5 2024-10-15 LTS OpenJDK Runtime Environment Temurin-21.0.5+11 (build 21.0.5+11-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.5+11 (build 21.0.5+11-LTS, mixed mode, sharing)

Quarkus version or git rev

3.17.2

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

Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256) Maven home: /home/zipper/.m2/wrapper/dists/apache-maven-3.9.8-bin/337e6d14/apache-maven-3.9.8 Java version: 21.0.5, vendor: Eclipse Adoptium, runtime: /home/zipper/.sdkman/candidates/java/21.0.5-tem Default locale: en, platform encoding: UTF-8 OS name: "linux", version: "5.15.167.4-microsoft-standard-wsl2", arch: "amd64", family: "unix"

Additional information

The bug is also present in earlier versions.

[quarkus-bot]

/cc @FroMage (rest), @stuartwdouglas (rest)

[geoand]

I would be surprised if this is a bug to be honest, as I am pretty sure that @Consumes needs to be on SubtestResource and not on MultipartResource.

@FroMage do you remember if @Produces and @Consumes should be placed on the subresource or the original resource?

[bjornpalmqvist]

With legacy rest framework that implementaion work, but when I uppgraded to the new rest implementation it stopped working.

[FroMage]

As I suspected, it's due to the @Consumes(JSON) on the intermediate endpoint. That will cause the multipart payload to be rejected.

If I remove it, the test passes.

Now, I'd have to check the spec to see whether @Consumes should be ignored on sub-resource locators.

[FroMage]

According to https://jakarta.ee/specifications/restful-ws/4.0/jakarta-restful-ws-spec-4.0#request_matching we should do the matching first based on path to find the candidate methods.

Once we have all the methods (and this will have invoked the locator method to obtain the locator instance on which to find the end method), we then check that the method accepts the right HTTP method, and content types.

This implies that we first find the endpoint method (through every matching locator) and only at the end do we check for that method's content types.

From what I understand of this, only the method @Produces/Consumes annotations of the end method, and if missing, its containing class should be considered.

In this case, the @Consumes(JSON) of SubtestResource should be completely ignored and only the one defined on MultipartResource should be considered.

Sorry :(

[FroMage]

Mmm, completed by what?

I meant that our implementation should be fixed to ignore the @Consumes annotation on the SubtestResource and only respect the one from MultipartResource, sorry if I wasn't clear. This sounds like a bug :(

[geoand]

I read your comments the exact opposite way.

Reopening

[geoand]

@FroMage do you have a fix in mind?

[FroMage]

I read your comments the exact opposite way.

Sorry I should have been clearer, obviously :(

Do you have a fix in mind?

I don't remember how we handle locators, but I suppose that in the case of locator matches we have to move the content-type check steps further down the chain.

[geoand]

I don't remember how we handle locators

I don't think I ever knew 😆

[FroMage]

Honestly, I'm still surprised anytime someone uses them.

[geoand]

Same :)