[asterisk-bugs] [JIRA] (ASTERISK-28231) res_http_websocket: Not responding to Connection Close Frame (opcode 8)
Jeremy Lainé (JIRA)
noreply at issues.asterisk.org
Fri Jan 4 11:02:47 CST 2019
[ https://issues.asterisk.org/jira/browse/ASTERISK-28231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Lainé updated ASTERISK-28231:
------------------------------------
Attachment: websocket-close-v2.patch
Version 2 of my patch has some additional fixes:
- payload_len is zeroed out to avoid the client reading from our temporary buffer
- the stream is actually closed
Note: the call to ast_websocket_close takes care of setting session->closing so we don't need to set it ourselves.
> res_http_websocket: Not responding to Connection Close Frame (opcode 8)
> -----------------------------------------------------------------------
>
> Key: ASTERISK-28231
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-28231
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Resources/res_http_websocket
> Affects Versions: 16.0.1
> Reporter: Jeremy Lainé
> Labels: patch
> Attachments: test-ws.py, websocket-close.patch, websocket-close-v2.patch
>
>
> Asterisk's WebSocket implementation does not seem to respond to opcode 8, meaning that a client client which tries to close the WebSocket cleanly ends up hanging.
> Quoting RFC 6455 section 5.5.1 Close:
> {quote}
> If an endpoint receives a Close frame and did not previously send a
> Close frame, the endpoint MUST send a Close frame in response.
> {quote}
> I can reproduce this 100% against Asterisk 16.0.1 using a trivial Python script.
> NOTE: it would probably be good to run the full autobahn test suite to shake out any other quirks: https://github.com/crossbario/autobahn-testsuite
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list