Unable to use custom handlers for HTTP OPTIONS method in subresources

[mabartos]

Describe the bug

[Breaking change in 3.15.2 minor release]

After merging #43440, we (Keycloak) are not able to use our custom logic for handling the HTTP OPTIONS method in Quarkus REST subresources. When there's an HTTP request with the OPTIONS method made for a subresource that does not explicitly contain a handler annotated with @OPTIONS, default values are immediately returned. However, when some specific handlers are nested deeper in subresources, they are not taken into account.

Previously, all subresources were traversed and checked whether they contain the handler for @HEAD, and @OPTIONS HTTP methods.

Expected behavior

Use custom nested handlers for @OPTIONS and @HEAD HTTP methods.

Actual behavior

NOT POSSIBLE to use custom nested handlers for @OPTIONS and @HEAD HTTP methods.

How to Reproduce?

1. Have custom handlers for OPTIONS and HEAD methods in sub-resources
2. Make an OPTIONS/HEAD HTTP request for them, or leverage preflight logic
3. See the custom handler is not executed, but some default response is returned

Output of uname -a or ver

Linux mabartos 6.11.9-100.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Nov 17 18:52:19 UTC 2024 x86_64 GNU/Linux

Output of java -version

openjdk 21.0.3 2024-04-16 LTS OpenJDK Runtime Environment Temurin-21.0.3+9 (build 21.0.3+9-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.3+9 (build 21.0.3+9-LTS, mixed mode, sharing)

Quarkus version or git rev

3.15.2

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

Maven 3.9.8

Additional information

I'll provide a PR for this.

Maybe it would be good to go through the same case in the ClassRoutingHandler containing also the default mechanisms for OPTIONS/HEAD. But it's out of scope of this issue.

[mabartos]

@geoand @cescoffier Could you please check it?

[mabartos]

It should be backported to 3.15.x

[quarkus-bot]

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