Don't convert WebApplicationException in REST Client when produced by a custom mapper

[geoand]

The idea is that if a user has opted to create an exception, we should always honor it - even if it's a WebApplicationException

• Fixes: REST Client Replaces WebApplicationException Instances Returned By ExceptionMapper #42275

[geoand]

@FroMage WDYT?

[FroMage]

My only objection would be the original security mistake of JAX-RS which is that client and server share the same exception type, and so it's too easy for client calls to leak client call details to server users. Things like status code, reason, headers, bodies.

That's why our clients don't throw WebApplicationException instances. Now, in the case of custom mappers… Given that they're separate exception mappers to the server mappers, perhaps that's alright. But given that the original issue was avoiding security leaks, make sure you keep this in mind while reviewing the feature?

I can't think a security reason to refuse this PR, myself.

[geoand]

But given that the original issue was avoiding security leaks, make sure you keep this in mind while reviewing the feature?

Yeah, the use in the reported issue is legit and does things properly

[geoand]

@FroMage mind reviewing this?

Thanks

[FroMage]

LGTM

[geoand]

🙏🏼

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit c6b03f9.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.