Closed akka-ci closed 7 years ago
Comment by ktoso Tuesday Jan 05, 2016 at 20:19 GMT
Thanks a lot for collecting the instances and RFC together. I agree that this should be: implemented, optional, yet default.
That seems to be the most typical use case and when someone wants to do the "I'm still streaming my stuff and will close soon" they'll start looking and find the other version.
API wise WDYT about having options on the handleWebsocketMessages
method? Alternative would be different method, but seems less appealing to me somehow.
I'm happy to take this on if you'd prefer to focus on some other ticket from the :next ones?
Comment by rklaehn Friday May 13, 2016 at 13:41 GMT
+1 for having extra parameters on handleWebsocketMessages
, with automatic closing the default.
Comment by ktoso Thursday May 19, 2016 at 00:24 GMT
Triaged, let's do it – should not be too hard. If someone is interested in contributing this one let us know!
Will be fixed by #860.
Issue by jrudolph Tuesday Jan 05, 2016 at 19:37 GMT Originally opened as https://github.com/akka/akka/issues/19359
Currently, the client handler can choose when to close a Websocket connection by issuing completion on the outgoing side of the Websocket handler flow. This is also valid when the peer already tried to close the connection.
In #19285 and #19346 (and myself in https://github.com/jrudolph/akka-http-scala-js-websocket-chat) people have shown to expect that the WS connection is closed automatically when the peer tries to close it.
Effectively, it boils down to the question whether WS supports half-closed connections. RFC 6455 says
So, that's not really a definite answer as well.
It may still make sense to implement (optional but default?) auto-closing of the WS connection when the peer has closed the connection.