[Asterisk-code-review] res http websocket: respond to CLOSE opcode (asterisk[16])

Jeremy Lainé asteriskteam at digium.com
Tue Jan 15 13:28:54 CST 2019


Jeremy Lainé has posted comments on this change. ( https://gerrit.asterisk.org/10861 )

Change subject: res_http_websocket: respond to CLOSE opcode
......................................................................


Patch Set 2:

OK this is turning into something of a rabbithole!

Some things I don't understand:

- the documentation for ast_websocket_read (and ast_websocket_readingstring) state: "Once an AST_WEBSOCKET_OPCODE_CLOSE opcode is received the socket will be closed". Am I to understand this is not true, and we don't want it to be?

- the documentation also states that the caller is responsible for freeing the payload, but I don't think that's true either. From what I understand we have a session->payload whose alllocation is managed internally by ast_websocket_read. By the looks of it we keep appending data onto session->payload .. until we receive a frame with a zero payload length? The returned "payload" is set to point to the start of session->payload.

To be honest the handling of fragmented data looks rather brittle, if  we receive a PONG in the middle of a fragmented message (which is allowed according RFC 6455) I'm pretty sure we end up with a corrupt payload.


-- 
To view, visit https://gerrit.asterisk.org/10861
To unsubscribe, or for help writing mail filters, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: 16
Gerrit-MessageType: comment
Gerrit-Change-Id: Icb1b60205fc77ee970ddc91d1f545671781344cf
Gerrit-Change-Number: 10861
Gerrit-PatchSet: 2
Gerrit-Owner: Jeremy Lainé <jeremy.laine at m4x.org>
Gerrit-Reviewer: Friendly Automation (1000185)
Gerrit-Reviewer: Jeremy Lainé <jeremy.laine at m4x.org>
Gerrit-Reviewer: Joshua C. Colp <jcolp at digium.com>
Gerrit-Reviewer: Sean Bright <sean.bright at gmail.com>
Gerrit-Comment-Date: Tue, 15 Jan 2019 19:28:54 +0000
Gerrit-HasComments: No
Gerrit-HasLabels: No
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20190115/0fe7f617/attachment.html>


More information about the asterisk-code-review mailing list