Closing of websocket by remote server does not trigger the script close handler #581
Comments
na--
changed the title
|
Any updates? 😅 |
|
@jonathandemoor unfortunately not at this time, sorry... |
|
On related note I just got a panic in the ws test: This has never happened before and I do a lot of test runs :) I can't at the moment look into it but it might be relevant |
|
We already have a WS close test that checks if the It seems that k6 is not properly handling a server-initiated close. Will look into this. |
imiric
pushed a commit
that referenced
this issue
Oct 4, 2019
This avoids a hanging behavior when the server closes the WS connection, either via a control close frame[1] or by closing the connection prematurely without sending the control frame (deviating from the WS protocol). If the control close frame is not received but the connection is closed, the error (`close 1006 (abnormal closure): unexpected EOF`) will be returned to the user's WS error handler, as it indicates an issue with the server. The user-specified close handler should be called in either case now. Closes #581 [1]: https://tools.ietf.org/html/rfc6455#section-5.5.1
imiric
pushed a commit
that referenced
this issue
Oct 23, 2019
This avoids a hanging behavior when the server closes the WS connection, either via a control close frame[1] or by closing the connection prematurely without sending the control frame (deviating from the WS protocol). If the control close frame is not received but the connection is closed, the error (`close 1006 (abnormal closure): unexpected EOF`) will be returned to the user's WS error handler, as it indicates an issue with the server. The user-specified close handler should be called in either case now. Closes #581 [1]: https://tools.ietf.org/html/rfc6455#section-5.5.1
imiric
pushed a commit
that referenced
this issue
Oct 25, 2019
This avoids a hanging behavior when the server closes the WS connection, either via a control close frame[1] or by closing the connection prematurely without sending the control frame (deviating from the WS protocol). If the control close frame is not received but the connection is closed, the error (`close 1006 (abnormal closure): unexpected EOF`) will be returned to the user's WS error handler, as it indicates an issue with the server. The user-specified close handler should be called in either case now. This required rewriting the test httpmultibin WS server handlers, since the previous ones don't comply with the WS spec. New test code shouldn't use the `*-invalid` endpoints, which are there only for compatibility with existing tests, which should be rewritten soon. Closes #581 [1]: https://tools.ietf.org/html/rfc6455#section-5.5.1
imiric
pushed a commit
that referenced
this issue
Oct 28, 2019
This avoids a hanging behavior when the server closes the WS connection, either via a control close frame[1] or by closing the connection prematurely without sending the control frame (deviating from the WS protocol). If the control close frame is not received but the connection is closed, the error (`close 1006 (abnormal closure): unexpected EOF`) will be returned to the user's WS error handler, as it indicates an issue with the server. The user-specified close handler should be called in either case now. This required rewriting the test httpmultibin WS server handlers, since the previous ones don't comply with the WS spec. New test code shouldn't use the `*-invalid` endpoints, which are there only for compatibility with existing tests, which should be rewritten soon. Closes #581 [1]: https://tools.ietf.org/html/rfc6455#section-5.5.1
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When the remote server closes the websocket like this, the
closehandler in the script is not called and the script iteration never finishes executing, it becomes stuck in the websocket handling code.The
errorhandler is called with an error likeGoError: An unexpected error occured: websocket: close 1006 (abnormal closure): unexpected EOF...., which is probably also suboptimal.The text was updated successfully, but these errors were encountered: