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
Both Bandit and Cowboy validate UTF-8 of text frames, per spec, but Channels push JSON which are also validated against UTF-8. Therefore, I suggest we use a binary frame for pushing JSON.
Our serializers already handle binary frames, but they always start with the bytes 0, 1, and 2. So there is no clash with JSON and we can start sending JSON over binaries frames without introducing a new serializer version. However, we may want to have a flag on the client that forces it over text instead for those who for some reason need to run against other serializers.
Good catch! As you know, UTF-8 validation is a surprisingly expensive operation and is usually near the top of profiling analysis of Bandit's WebSocket stack. It's an expensive thing to double up on for sure.
I agree that binary probably makes the most sense here (the spec is pretty loose about which one to use where; binary is mostly considered a simpler 'all bets are off' option that would apply well here). Absent that, both Bandit and Cowboy have flags to disable UTF-8 validation.
Both Bandit and Cowboy validate UTF-8 of text frames, per spec, but Channels push JSON which are also validated against UTF-8. Therefore, I suggest we use a binary frame for pushing JSON.
Our serializers already handle binary frames, but they always start with the bytes 0, 1, and 2. So there is no clash with JSON and we can start sending JSON over binaries frames without introducing a new serializer version. However, we may want to have a flag on the client that forces it over text instead for those who for some reason need to run against other serializers.
/cc @mtrudel
The text was updated successfully, but these errors were encountered: