[asterisk-bugs] [JIRA] (ASTERISK-28257) res_http_websocket: PING / PONG opcodes break data reception

[Friendly Automation (JIRA)]

    [ 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)