[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