Closed joffrey-bion closed 5 months ago
Use different types in generally more appealing, because the API is not "lying" by advertising a headers
parameter that is not respected and fails the call.
However, it's not always technically possible to implement different interfaces when the header support of the implementation depends on factors that Krossbow doesn't control. For instance, when wrapping Ktor's web socket, the support depends on the engine, which is not statically known.
We'll have to go the other way: using a property.
Some
WebSocketClient
implementations do not support sending custom headers in the handshake, and this cannot be implemented in Krossbow. Here are some cases where it's just not possible right now:Calling
connect()
with a non-empty headers map on these clients currently causes anIllegalArgumentException
. It would be nice to allow consumers to check up front whether the client supports custom headers.Possible implementations:
supportsCustomHeaders: Boolean
onWebSocketClient
WebSocketClient
types, one with theconnect()
method that takes aheaders
param and one that doesn't.It would also simplify tests.