[asterisk-bugs] [JIRA] (ASTERISK-28257) res_http_websocket: PING / PONG opcodes break data reception
Friendly Automation (JIRA)
noreply at issues.asterisk.org
Mon Jan 28 07:24:50 CST 2019
[ https://issues.asterisk.org/jira/browse/ASTERISK-28257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=246065#comment-246065 ]
Friendly Automation commented on ASTERISK-28257:
------------------------------------------------
Change 10916 merged by George Joseph:
res_http_websocket: ensure control frames do not interfere with data
[https://gerrit.asterisk.org/10916|https://gerrit.asterisk.org/10916]
> res_http_websocket: PING / PONG opcodes break data reception
> ------------------------------------------------------------
>
> Key: ASTERISK-28257
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-28257
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Resources/res_http_websocket
> Affects Versions: 13.24.1, 16.1.1
> Reporter: Jeremy Lainé
> Assignee: Jeremy Lainé
> Attachments: mix-ping-and-fragmented-data.py
>
>
> Currently, PING / PONG opcodes are handled together with data reception. At a high level the logic looks like:
> - retrieve frame header
> - retrieve frame payload and apply unmasking
> - (reply to PING and stop here ONLY if replying fails)
> - (handle CLOSE opcode and stop here)
> - put payload into a re-assembly buffer and return it to the caller
> When data and PING / PONG opcodes and data are received consecutively, Asterisk behaves properly. However RFC 6455 specifies that control opcodes (PING / PONG / CLOSE) can be received in the middle of a fragmented message. In this case, Asterisk's logic breaks down, resulting in a truncated message being received.
> My suggestion to fix this is to align the behavior with the new CLOSE handling code and return immediately, without exposing the payload to the caller.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list