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

[Sean Bright]

Sean Bright has posted comments on this change. ( https://gerrit.asterisk.org/10861 )

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


Patch Set 2:

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

It is _sort of_ true. But ast_websocket_read() is not currently what is closing the socket. The echo protocol handler in res_http_websocket and the sip protocol handler in res_pjsip_transport_websocket both call ast_websocket_unref() when their read loops exit, and - assuming the refcount has dropped to 0 - the AO2 destructor calls ast_websocket_close().

 > and we don't want it to be?

I think we do want it to be true, but I also want to make sure that we are fixing the right problem. If we were properly unref'ing the PJSIP transport in pjsip_transport_management.c (deleting the scheduler entry and unref'ing the object), then the WS socket _would_ close immediately with the current code (albeit with the wrong status code).

In other words, I don't think we should be calling ast_iostream_close() from within ast_websocket_read(). I think what we really should do is:

1) pjsip_transport_management.c: When we are notified that the transport is shutdown/disconnected, we should unschedule and unref the transport. We already remove it from the transports container when this occurs, but there is still a ref 'owned' by the scheduler context.

2) res_http_websocket.c: When the client sends us a CLOSE, we should save off the status code in the ast_websocket structure and use that saved off status code in session_destroy_fn.

 > - 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.

Yes, this code is a bit hard to follow.

 > 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.

Ditto. We fail the autobahn testsuite spectacularly (don't even try the UTF-8 tests or you'll be sad).


-- 
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 21:29:58 +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/0bc0aa58/attachment.html>