-
Notifications
You must be signed in to change notification settings - Fork 7
Open
Description
I came a cropper of a bug that I debugged like this
--- a/lib/Cro/WebSocket/BodyParsers.pm6
+++ b/lib/Cro/WebSocket/BodyParsers.pm6
@@ -30,6 +30,7 @@ class Cro::WebSocket::BodyParser::JSON does Cro::BodyParser {
method parse($message) {
$message.body-blob.then: -> $blob-promise {
+ CATCH { say "Not good stuff: " ~ $blob-promise.result.gist }
from-json $blob-promise.result.decode('utf-8')
}
}
The RFC says the first two bytes are an unsigned integer and the rest is whatever.
If there is a body, the first two bytes of the body MUST be a 2-byte unsigned integer (in network byte order) representing a status code with value /code/ defined in Section 7.4. Following the 2-byte integer, the body MAY contain UTF-8-encoded data with value /reason/, the interpretation of which is not defined by this specification.
A websocket I tested with sends non-JSON as reason, but it chokes on decode('utf-8') anyway.
I think close frames should be handled specially but I'm still too novice at this to risk a submission.
Altai-man and kawaii
Metadata
Metadata
Assignees
Labels
No labels