<blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><ul><li>the documentation for ast_websocket_read (and ast_websocket_readingstring)</li><li>state: "Once an AST_WEBSOCKET_OPCODE_CLOSE opcode is received the</li><li>socket will be closed". Am I to understand this is not true</li></ul></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">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().</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">and we don't want it to be?</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">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).</p><p style="white-space: pre-wrap; word-wrap: break-word;">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:</p><p style="white-space: pre-wrap; word-wrap: break-word;">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.</p><p style="white-space: pre-wrap; word-wrap: break-word;">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.</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><ul><li>the documentation also states that the caller is responsible for</li><li>freeing the payload, but I don't think that's true either. From</li><li>what I understand we have a session->payload whose alllocation is</li><li>managed internally by ast_websocket_read. By the looks of it we</li><li>keep appending data onto session->payload .. until we receive a</li><li>frame with a zero payload length? The returned "payload" is set to</li><li>point to the start of session->payload.</li></ul></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">Yes, this code is a bit hard to follow.</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">To be honest the handling of fragmented data looks rather brittle,<br>if  we receive a PONG in the middle of a fragmented message (which<br>is allowed according RFC 6455) I'm pretty sure we end up with a<br>corrupt payload.</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">Ditto. We fail the autobahn testsuite spectacularly (don't even try the UTF-8 tests or you'll be sad).</p><p><a href="https://gerrit.asterisk.org/10861">View Change</a></p><ul style="list-style: none; padding: 0;"></ul><p>To view, visit <a href="https://gerrit.asterisk.org/10861">change 10861</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.asterisk.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.asterisk.org/10861"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: asterisk </div>
<div style="display:none"> Gerrit-Branch: 16 </div>
<div style="display:none"> Gerrit-MessageType: comment </div>
<div style="display:none"> Gerrit-Change-Id: Icb1b60205fc77ee970ddc91d1f545671781344cf </div>
<div style="display:none"> Gerrit-Change-Number: 10861 </div>
<div style="display:none"> Gerrit-PatchSet: 2 </div>
<div style="display:none"> Gerrit-Owner: Jeremy Lainé <jeremy.laine@m4x.org> </div>
<div style="display:none"> Gerrit-Reviewer: Friendly Automation (1000185) </div>
<div style="display:none"> Gerrit-Reviewer: Jeremy Lainé <jeremy.laine@m4x.org> </div>
<div style="display:none"> Gerrit-Reviewer: Joshua C. Colp <jcolp@digium.com> </div>
<div style="display:none"> Gerrit-Reviewer: Sean Bright <sean.bright@gmail.com> </div>
<div style="display:none"> Gerrit-Comment-Date: Tue, 15 Jan 2019 21:29:58 +0000 </div>
<div style="display:none"> Gerrit-HasComments: No </div>
<div style="display:none"> Gerrit-HasLabels: No </div>