Javascript Post请求看起来像ESP8266上的两个不同请求。这是一个Chrome bug吗？

我正在ESP8266 WiFi模块上设置服务器。基本操作是，您请求一个URL。ESP服务于该页面。它有一种形式。填写后单击submit，浏览器通过AJAX发送POST请求。我没有使用jQuery，只是使用js。从Chrome开发工具来看，一切似乎都很好

但是在ESP服务器端，我注意到我偶尔会丢失post数据。经过深入挖掘，我发现了这个问题

在我的windows上使用Chrome的理想效果是：这是正确的。Post数据如预期的那样出现

+IPD，0507:POST/wifi.htm HTTP/1.1
主机：192.168.4.1
连接：保持活力
内容长度：63
来源：http://192.168.4.1
用户代理：Mozilla/5.0（Windows NT 10.0；WOW64）AppleWebKit/537.36（KHTML，如Gecko）Chrome/53.0.2785.143 Safari/537.36
内容类型：文本/纯文本；字符集=UTF-8
接受：*/*
推荐人：http://192.168.4.1/wifi.htm
接受编码：gzip，deflate
接受语言：en-US，en；q=0.8
AlexaToolbar-ALX_NS_PH:AlexaToolbar/ALX-4.0
ethOrWiFi=1&ewln=1&dhcp=1&ssid=e传感器&key=tgfgfdgdgdrd&auth=4

但在我的Mac Chrome上，我看到了以下结果

+IPD，0472:POST/wifi.htm HTTP/1.1
主机：192.168.4.1
连接：保持活力
内容长度：63
来源：http://192.168.4.1
用户代理：Mozilla/5.0（Macintosh；英特尔Mac OS X 10_12_0）AppleWebKit/537.36（KHTML，如Gecko）Chrome/53.0.2785.143 Safari/537.36
内容类型：文本/纯文本；字符集=UTF-8
接受：*/*
DNT:1
推荐人：http://192.168.4.1/wifi.htm
接受编码：gzip，deflate
接受语言：en-US，en；q=0.8毫升；q=0.6
AlexaToolbar-ALX_NS_PH:AlexaToolbar/ALX-4.0
+IPD，0,63:ethrwifi=1&ewln=1&dhcp=1&ssid=Esensors&key=asdfasdfasdf&auth=4

我可以重复一下。每种情况唯一不同的是我在Windows上使用的是Chrome，而不是Mac上的Chrome。为了再次检查，我下载了Chrome金丝雀版本并尝试了。第一个请求很有效。从第二次请求开始，它就显示了这个问题。为什么会这样？有什么想法吗？可能是我的笔记本电脑有问题吗？：）

下面是Chrome在Mac上的Chrome开发工具信息（有问题的那一个）

**请求头：**
POST/wifi.htm HTTP/1.1
主机：192.168.4.1
连接：保持活力
内容长度：61
来源：http://192.168.4.1
用户代理：Mozilla/5.0（Macintosh；英特尔Mac OS X 10_12_0）AppleWebKit/537.36（KHTML，如Gecko）Chrome/53.0.2785.143 Safari/537.36
内容类型：文本/纯文本；字符集=UTF-8
接受：*/*
DNT:1
推荐人：http://192.168.4.1/wifi.htm
接受编码：gzip，deflate
接受语言：en-US，en；q=0.8毫升；q=0.6
AlexaToolbar-ALX_NS_PH:AlexaToolbar/ALX-4.0
**请求有效载荷**
ethrwifi=1&ewln=1&dhcp=1&ssid=Esensors&key=asdfasdfoi&auth=4

+IPD是AT命令，表示从网络接收到数据<代码>+IPD，0,63:表示从连接0接收63字节。与

内容长度

标题匹配的。请注意，它也出现在请求的头部分的开头

---

ESP端的WiFi库正在将其加入。第281行是它可能发生的源代码。有几个变量会影响是否添加+IPD，可能是您设置了或无意中更改了一个。

您是否尝试通过WireShark或tcpdump捕获通信？我猜在头和数据被发送到另一个数据包后会出现刷新。但这不是TCP意义上的问题。它仍然是一个连接。头的唯一区别是不跟踪标志。我不认为这是一个解决方案，但可能值得通过从chrome设置中禁用它来测试。第二个请求有什么问题？你说的是

+IPD，0,63:

？@gre\u gor问题是，当ESP上的服务器捕获数据包时，它只将第一个数据集作为请求，并将其传递给代码的其余部分。因此，当这种情况发生时，我会错过post数据。我可以在服务器代码上做一些变通，但我不确定我是否理解这里的真正问题。这就是我发布这个问题的原因。任何操作系统上的Chrome都没有问题。你应该编写你的服务器，这样它就可以处理TCP流，即使你把数据分成块。是的，我知道了。我不明白的是，为什么在使用某些浏览器/机器时，它会在标题中添加+IPD，在发布数据之前添加另一个+IPD，以及为什么很少有其他浏览器/机器将其作为单一流（仅一个+IPD）显示。我认为这是因为发送到ESP的消息的长度实际上不同。在Mac请求中，收到了两个单独的数据包。如果你测量两个字符串的长度，PC版本显示为507，从开始到结束实际上是507，但MAC电脑显示为472，因此需要两个+IPD。可能是TCP设置。