Closing an SSL websocket bombs out. SSL sockets can only be closed in both directions at once, but websockets send a FRAME_CLOSE and then close in the write direction only.
Is it necessary to close in the write direction only, or can the websocket simply close both ends at once?
The exception can't easily be dealt with, since it happens in the backend.
Demo code available here. If you don't have a certificate, it'll generate a self-signed; the behaviour is the same.
https://github.com/Rosuav/StilleBot/blob/master/ws_halfclose.pike
ChrisA
On 2020-08-07 13:49, Chris Angelico wrote:
Closing an SSL websocket bombs out. SSL sockets can only be closed in both directions at once, but websockets send a FRAME_CLOSE and then close in the write direction only.
Is it necessary to close in the write direction only, or can the websocket simply close both ends at once?
The exception can't easily be dealt with, since it happens in the backend.
Demo code available here. If you don't have a certificate, it'll generate a self-signed; the behaviour is the same.
https://github.com/Rosuav/StilleBot/blob/master/ws_halfclose.pike
ChrisA
Hi Chris,
I think the websocket rfc does not require the connection to be closed in one direction. It only says that the side which sent the close frame may not send any other frames. I think it would be safe to change the current behavior and only close the connection (in both directions) after receiving the close response.
Arne
On Wed, Aug 12, 2020 at 5:59 PM Arne Goedeke el@laramies.com wrote:
On 2020-08-07 13:49, Chris Angelico wrote:
Closing an SSL websocket bombs out. SSL sockets can only be closed in both directions at once, but websockets send a FRAME_CLOSE and then close in the write direction only.
Is it necessary to close in the write direction only, or can the websocket simply close both ends at once?
The exception can't easily be dealt with, since it happens in the backend.
Demo code available here. If you don't have a certificate, it'll generate a self-signed; the behaviour is the same.
https://github.com/Rosuav/StilleBot/blob/master/ws_halfclose.pike
ChrisA
Hi Chris,
I think the websocket rfc does not require the connection to be closed in one direction. It only says that the side which sent the close frame may not send any other frames. I think it would be safe to change the current behavior and only close the connection (in both directions) after receiving the close response.
Cool. Since, from my reading, that is already happening (WebSocket.pmod line 818), that means that the write-direction-close on line 868 can simply be removed, correct?
Should this change be made in 8.0 or just master?
ChrisA
On 2020-08-12 10:15, Chris Angelico wrote:
On Wed, Aug 12, 2020 at 5:59 PM Arne Goedeke el@laramies.com wrote:
On 2020-08-07 13:49, Chris Angelico wrote:
Closing an SSL websocket bombs out. SSL sockets can only be closed in both directions at once, but websockets send a FRAME_CLOSE and then close in the write direction only.
Is it necessary to close in the write direction only, or can the websocket simply close both ends at once?
The exception can't easily be dealt with, since it happens in the backend.
Demo code available here. If you don't have a certificate, it'll generate a self-signed; the behaviour is the same.
https://github.com/Rosuav/StilleBot/blob/master/ws_halfclose.pike
ChrisA
Hi Chris,
I think the websocket rfc does not require the connection to be closed in one direction. It only says that the side which sent the close frame may not send any other frames. I think it would be safe to change the current behavior and only close the connection (in both directions) after receiving the close response.
Cool. Since, from my reading, that is already happening (WebSocket.pmod line 818), that means that the write-direction-close on line 868 can simply be removed, correct?
Should this change be made in 8.0 or just master?
ChrisA
Sounds like it, yes. Let's fix this on master first and backport it 'soon'. This way people get a chance to complain.
Arne
On Wed, Aug 12, 2020 at 6:40 PM Arne Goedeke el@laramies.com wrote:
Sounds like it, yes. Let's fix this on master first and backport it 'soon'. This way people get a chance to complain.
By "soon" do you mean "commit to the 8.0 branch now and have it in the next release"? Because that's what I would normally do if it's going to go to 8.0 at all. Or is there some other cadence to align with?
ChrisA
pike-devel@lists.lysator.liu.se
-
Arne Goedeke -
Chris Angelico