-
Notifications
You must be signed in to change notification settings - Fork 19
Description
Currently we are offering an implementation of the "low-level" WSClient instead of the WSClientHighLevel:
http4s-jdk-http-client/core/src/main/scala/org/http4s/jdkhttpclient/JdkWSClient.scala
Lines 45 to 48 in b360b86
| /** Create a new `WSClient` backed by a JDK 11+ http client. */ | |
| def apply[F[_]]( | |
| jdkHttpClient: HttpClient | |
| )(implicit F: Async[F]): WSClient[F] = |
It's not stated explicitly, but the implication is that when using the "low-level" interface the user is responsible for handling pings and close frames. For example, only the high-level interface promises to do this and does so in the default implementation.
However, the JDK WebSocket already handles those for us.
WebSocket handles received Ping and Close messages automatically (as per the WebSocket Protocol) by replying with Pong and Close messages. If the listener receives Ping or Close messages, no mandatory actions from the listener are required.
This defies expectations and causes bugs: in the high-level connection implementation pings and close frames are handled manually. But because the JDK client is also handling these, that causes them to be handled to twice, which leads to protocol violations and I/O errors.
My best proposal to fix this is to make a breaking bump and offer only the WSClientHighLevel going forward.
h/t @yurique for reporting and investigation.