Cannot open WebSocket with Sec-WebSocket-Protocol header in Quarkus version 3.7.1 and above with quarkus-websockets package about quarkus

[sberyozkin]

I'm not seeing anything in https://github.com/quarkusio/quarkus/commits/main/extensions/websockets that might've caused it. @mkouba @cescoffier, please comment if you have some ideas

[mkouba]

@paolo-cutilli-eudata Hm, I've tried to connect to the endpoint using new WebSocket("ws://" + location.host + "/ws", "custom-protocol") in JS and it seems to work - I can even see the log message Socket opened: abcdef... in the console. In fact, the protocols paremeter seems to be ignored completely. I don't know if that's expected though, in the sense that the server can fall back to the default protocol if no matching protocol is found.

By the way, I don't think that @RequestScoped is a good match for a jakarta.websocket server endpoint. The spec does not say anything about CDI contexts so I'd say that @ApplicationScoped/@Dependent would be a "safer" choice.

[paolo-cutilli-eudata]

@mkouba thank you for the suggestion about the @RequestScoped annotation.

regarding the WebSocket, i tried your approach in JS directly from the /q/dev page and i cannot open the WebSocket.
i can see the open log message too, but immediatly followed by the close message

Socket opened: pBnZ5eTS0EYXXBFK-KunRgXVdcMgFoMt_-rdsF-7
Socket closed: pBnZ5eTS0EYXXBFK-KunRgXVdcMgFoMt_-rdsF-7 - 

and the following error

is there additional information that i can give you so that you can reproduce the problem?

[mkouba]

Hm, I do not observe this behavior 🤷.

is there additional information that i can give you so that you can reproduce the problem?

I can't think of anything.

[paolo-cutilli-eudata]

@mkouba I gathered some other interesting information. The same test described above works in Firefox.
From Chrome it does not work. I tried Postman WebSocket also and it does not work from there. I have Postman installed as a snap package on Ubuntu that i think it's based on electron/chromum engine. Do you think that this can be useful to circumscribe the problem?

[mkouba]

@mkouba I gathered some other interesting information. The same test described above works in Firefox. From Chrome it does not work. I tried Postman WebSocket also and it does not work from there. I have Postman installed as a snap package on Ubuntu that i think it's based on electron/chromum engine. Do you think that this can be useful to circumscribe the problem?

It might be related. On the other hand, I've tried with Chromium (Version 122.0.6261.94 (Official Build) snap (64-bit)) and it worked just fine.

[paolo-cutilli-eudata]

@mkouba I gathered some other interesting information. The same test described above works in Firefox. From Chrome it does not work. I tried Postman WebSocket also and it does not work from there. I have Postman installed as a snap package on Ubuntu that i think it's based on electron/chromum engine. Do you think that this can be useful to circumscribe the problem?

It might be related. On the other hand, I've tried with Chromium (Version 122.0.6261.94 (Official Build) snap (64-bit)) and it worked just fine.

Same configuration - Chromium Version 122.0.6261.94 (Official Build) snap (64-bit) - throws this error

[mkouba]

@sberyozkin Could you pls run this ^ test too?

[istosSchulz]

We have the exact same issue after upgrading to Quarkus 3.8.1. We downgraded to 3.6.9 to get it working. The upgrade to 3.7.0/3.7.1 seems to be the one that breaks it.
Same errors and behaviour. Our custom protocol is called differently but the issue seems to be the same. @OnOpen is called seemingly successful and immediately afterwards @OnClose is called. The client (Postman) reports "Error: Server sent no subprotocol".
We've integrated a ServerEndpointConfig.Configurator to inspect the request and response objects while handshake is happening but they seem to be ok. They contain the exact same headers in the working and in the broken version of Quarkus. When @OnClose is called the reported CloseReason is Going Away (1001).

[cescoffier]

It is likely due to:

• quarkusio/quarkus-http@805bb3f

[cescoffier]

Confirmed - See quarkusio/quarkus-http#143.