WIP: Prevent crash on WebSocket request to non-WebSocket node. #106
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This provides a partial fix for #51 to prevent the Guru from having to meditate. It's been tested on ESP32.
This now checks the HTTPNode type if a WebSocket was requested and only proceeds if the node is in fact a WebSocket, thus preventing the
newHandler()
call from failing on normal HTTP nodes.TODO
Right now I'm calling
raiseError(404...
because that was the first copypaste I can find. I'm not actually sure the best way to reject the websocket connection as I'm not familiar with this library (just picked it up yesterday). This code is sufficient to move the crash over to the client side, which reports a bad frame header now.A proper rejection should be sent, however that is accomplished in WebSocket land.
Testing
Clone and run the WebSocket chat server example from the master branch, and use https://www.websocket.org/echo.html to connect to the root URL on the device. This should panic and reset your ESP32. Connecting to
/chat
should work as expected.Check out this PR and do the same. The ESP32 should no longer panic, and report the rejection of non-WebSocket request.