Websocket-Chrome抱怨掩码位设置 [英] Websocket - Chrome complaining about mask bit set

查看:46
本文介绍了Websocket-Chrome抱怨掩码位设置的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已经在现有服务器中实现了一个websocket服务器.握手很好,然后我什至可以发送第一条消息,客户端浏览器就会收到它.但是任何后续消息都会断开websocket.在chrome上,出现以下错误.

I have implemented a websocket server in my existing server. Handshake is good and then I can even send first message and client browser receives it. But any subsequent messages disconnect websocket. On chrome I get following error.

failed: A server must not mask any frames that it sends to the client.

我的框架是这样创建的

Len = erlang:size(Msg),
if
        Len < 126 ->
             Message = [<<1:1, 0:3,2:4,0:1,Len:7>>,Msg];
        Len < 65536 ->
             Message = [<<1:1, 0:3,2:4,0:1,126:7,Len:16>>,Msg];
        true ->
             Message = [<<1:1, 0:3,2:4,0:1,127:7,Len:64>>,Msg]
 end,

现在要发送的一个样本数据如下所示<<< 130,46,60,115,110,112,95,105,110,102,111,32,97,118,95,112,111,116,61,34,49,49,34,32,104,97,110,100,115,95,112,101,114,95,104,111,117,114,61,34,48,46,50,48,34,3432,47,62 >>

Now one sample data to be transmitted looks like this <<130,46,60,115,110,112,95,105,110,102,111,32,97,118,95,112,111,116,61,34,49,49,34,32,104,97,110,100,115,95,112,101,114,95,104,111,117,114,61,34,48,46,50,48,34,32,47,62>>

如您在上面的代码中看到的,我的掩码位始终设置为0,但是我不解释为什么相同的消息第一次起作用,然后再次发送相同的消息,它抱怨掩码位设置了.

As you can see in the code above, my mask bit is always set to 0, but I don't why the same message works for the first time and then I send the same message again, it complains about mask bit set.

有人知道为什么吗?谢谢

Anybody got any idea why? Thanks

推荐答案

您粘贴的帧样本数据是理智的.

The frame sample data you pasted is sane.

48 bytes
ErlangSampleBytes[48] = 82 2E 3C 73 6E 70 5F 69  6E 66 6F 20 61 76 5F 70
                        6F 74 3D 22 31 31 22 20  68 61 6E 64 73 5F 70 65
                        72 5F 68 6F 75 72 3D 22  30 2E 32 30 22 20 2F 3E 

它解析/翻译为:

82 = fin:true
     rsv1:false
     rsv2:false
     rsv3:false
     opcode:2
2E = masked:false
     payloadLength:46 (decimal)
Payload = UTF8 valid: 
     <snp_info av_pot="11" hands_per_hour="0.20" />

您甚至不会发现有效载荷长度声明与样本缓冲区中剩余的内容不匹配.

You don't even have a mismatch on the payload length declaration and what is left in the sample buffer.

在这一点上,明智的做法是查看镀铬检查工具,以找出其认为得到的框架.然后,下一步就是尝试使用WireShark之​​类的工具捕获网络流量,以了解发生了什么.

At this point, it would be wise to look at the chrome inspection tooling to find out what the frames it thinks it got. And a next step after that would be to try to capture the network traffic with a tool like WireShark in an effort to see what is going on.

假设您在网络上发送的字节数与您在payloadLength中声明的字节数不同.(我见过的常见情况是发送的字节数超过了您声明的字节数)

Suspect that the # of bytes you are sending on the wire, vs what you are declaring in the payloadLength are differing. (common one i've seen is sending more bytes than you declare)

例如分配1024个字节的缓冲区,正确填充前48个字节,然后发送整个1024个字节.这将使下一帧的解析混乱.

Such as allocating a buffer of 1024 bytes, filling in the first 48 properly, then sending the entire 1024 bytes. That will mess parsing of the next frame.

这篇关于Websocket-Chrome抱怨掩码位设置的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆