Don't defer WebSocket opening #1348
Comments
slandelle
added a commit
that referenced
this issue
Feb 7, 2017
Motivation: We currently buffer WebSocket opening until first LastHttpContent reception with the UpgradeCallback. This doesn't make sense, and forces us to buffer any frame that might be sent along with the upgrade response. Modifications: * Drop UpgradeHandler that's never used as an abstraction * Perform upgrade/abort as soon as response is received * Ignore LastHttpContent * No need to buffer any frame Result: More simple code
slandelle
added a commit
that referenced
this issue
Feb 7, 2017
Motivation: We currently buffer WebSocket opening until first LastHttpContent reception with the UpgradeCallback. This doesn't make sense, and forces us to buffer any frame that might be sent along with the upgrade response. Modifications: * Drop UpgradeHandler that's never used as an abstraction * Perform upgrade/abort as soon as response is received * Ignore LastHttpContent * No need to buffer any frame Result: More simple code
slandelle
added a commit
that referenced
this issue
Mar 8, 2017
… Handler, close #1364 Motivation: Installing the WebSocket handler can trigger a read, so if there's a pending frame that was send along the HTTP upgrade response, we could crash because the handler is not properly configured yet. This is a regression caused by #1348. Modifications: Buffer frames until WebSocket is fully open. Result: No more crash when frames are sent along the HTTP upgrade response.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We currently buffer WebSocket opening until first
LastHttpContentreception with theUpgradeCallback.This doesn't make sense, and forces us to buffer any frame that might be sent along with the upgrade response.
WebSocketHandlerandWebSocketUpgradeHandlerneed serious clean up:UpgradeHandlerthat's never used as an abstractionLastHttpContentThe text was updated successfully, but these errors were encountered: