akka / akka-http

The Streaming-first HTTP server/module of Akka
https://doc.akka.io/libraries/akka-http/current/
Other
1.34k stars 594 forks source link

Consider auto-closing of WS connections on receipt of Close frame #95

Closed akka-ci closed 7 years ago

akka-ci commented 8 years ago

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

If an endpoint receives a Close frame and did not previously send a Close frame, the endpoint MUST send a Close frame in response. (When sending a Close frame in response, the endpoint typically echos the status code it received.) It SHOULD do so as soon as practical. An endpoint MAY delay sending a Close frame until its current message is sent (for instance, if the majority of a fragmented message is already sent, an endpoint MAY send the remaining fragments before sending a Close frame). However, there is no guarantee that the endpoint that has already sent a Close frame will continue to process data.

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.

akka-ci commented 8 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?

akka-ci commented 8 years ago

Comment by rklaehn Friday May 13, 2016 at 13:41 GMT


+1 for having extra parameters on handleWebsocketMessages , with automatic closing the default.

akka-ci commented 8 years ago

Comment by marekzebrowski Tuesday May 17, 2016 at 11:27 GMT


+1 for optional, default close

akka-ci commented 8 years ago

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!

akka-ci commented 8 years ago

Comment by danslapman Friday Jun 10, 2016 at 11:06 GMT


+1, please do it!

jrudolph commented 7 years ago

Will be fixed by #860.