You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
I came a cropper of a bug that I debugged like this
The RFC says the first two bytes are an unsigned integer and the rest is whatever.
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.
The text was updated successfully, but these errors were encountered: