WebSockets Next: make it possible to perform logic before the HTTP upgrade is started

[mkouba]

Description

Most likely introduce a new interface that can be implemented by CDI beans. We should be able to order the implementations (e.g. @Priority + @All List<T>).

The implementations should be able to inspect the HTTP request (headers etc.), reject the upgrade, ....

[michalvavrik]

Looks very interesting and will help me with #40622. Thanks

[michalvavrik]

Quarkus REST https://quarkus.io/guides/rest has https://javadoc.io/doc/io.quarkus.resteasy.reactive/resteasy-reactive/3.10.2/org/jboss/resteasy/reactive/server/ServerExceptionMapper.html that allows to register either global mapper for all the REST resources, or just for the one resources where the bean is produced.

For WS Next, it could be of interest to register this new interface for one endpoint only to avoid path-matching inside that bean.

[michalvavrik]

Maybe later though. Let's start with the global one.

[mkouba]

Maybe later though. Let's start with the global one.

Agreed. Let's start with the global one and improve later on (if needed ;-)

[geoand]

Definitely +1 on focusing on global and then moving to per class

[michalvavrik]

Definitely +1 on focusing on global and then moving to per class

hey @geoand , yes as far as user beans go, but it would be ineffective to have a global bean applied on every endpoint and then start matching request with a bean to determine if you need to run it. If I need to secure just one endpoint of all, I think it's better to have a local endpoint specific. in #40873 I added build item for that, so it's Quarkus internal but it will exist.

[geoand]

I'll have to have a look in a few days

[michalvavrik]

I'll have to have a look in a few days

sure, no hurry, thx

[geoand]

👍🏼

[mkouba]

Definitely +1 on focusing on global and then moving to per class

hey @geoand , yes as far as user beans go, but it would be ineffective to have a global bean applied on every endpoint and then start matching request with a bean to determine if you need to run it. If I need to secure just one endpoint of all, I think it's better to have a local endpoint specific. in #40873 I added build item for that, so it's Quarkus internal but it will exist.

@michalvavrik We could also add a method to the interface to be able to filter the endpoints by id, i.e. io.quarkus.websockets.next.WebSocket.endpointId().

interface HttpUpgradePolicy {

   boolean appliesTo(String endpointId);

   Uni<CheckResult> checkUpgrade(HttpUpgradeContext context);
}

[michalvavrik]

@michalvavrik We could also add a method to the interface to be able to filter the endpoints by id, i.e. io.quarkus.websockets.next.WebSocket.endpointId().

I like that, I can refactor #40873 to use that instead.

[michalvavrik]

Done.