Tcl http POST - 在 rPi 上通过 wlan0 发送时有效负载与 headers 分开
Tcl http POST - payload gets separated from headers when sent over wlan0 on rPi
我正在使用 ::http::geturl -query
从 rPi 向 ESP8266(第 3 方商业设备)发出带有小 json 负载的 HTTP POST 请求。它在通过 eth0 发送时有效,但在通过 wlan0 发送时失败。 tcpdump 显示通过 eth0 发送,消息作为单个数据包发送,但是当通过 wlan0 发送时,有效负载从 headers 中拆分并在第二个数据包中发送。 ESP8266 很可能是由于其数据包接收器的实现过于简单 and/or http 服务器似乎无法处理这种拆分。它在收到包含 headers 的数据包后发出 200 OK
响应,并且不处理请求的有效负载部分。
实验性地,我编写了由 ::http::geturl 发送的相同请求消息文本,并使用 nc
通过 wlan0 发送它;它作为单个数据包发送,并被 ESP8266 成功处理。
有没有人碰巧知道为什么使用 ::http 通过 wlan0 发送请求会以这个拆分消息结束,如果可以采取任何措施来防止它发生怎么办?
代码片段:
set s [::http::geturl http://$ip/con?com=cli -query $data -type application/json]
set r [::http::ncode $s]
::http::cleanup $s
Raspbian 软件包版本:
tcl8.6 8.6.9+dfsg-2
tcllib 1.19-dfsg-2
tcl_platform(engine) = Tcl
tcl_platform(machine) = armv7l
tcl_platform(os) = Linux
tcl_platform(osVersion) = 5.4.79-v7+
$ ifconfig wlan0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.101 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::ed38:71ab:13af:ae30 prefixlen 64 scopeid 0x20<link>
ether b8:27:eb:26:bf:94 txqueuelen 1000 (Ethernet)
来自/proc/cpuinfo
:
Hardware : BCM2835
Revision : a020d3
Model : Raspberry Pi 3 Model B Plus Rev 1.3
$ uname -a
Linux raspberrypi 5.4.79-v7+ #1373 SMP Mon Nov 23 13:22:33 GMT 2020 armv7l GNU/Linux
Tcl 的 http 包在写入 headers 和 [=33= 之间将 headers 刷新到套接字(即执行实际的 write()
/send()
) ] 的查询。对于 HTTP 服务器的任何正确实现,这都很好……但您没有使用它。出于某种原因,OS 内核中的 wlan 和 eth drivers 对于如何处理这种情况有不同的策略,eth driver 决定在发送前稍等片刻; Tcl 绝对不会配置套接字的这方面,保持系统默认值。 (我不知道如何配置 OS 默认值。)
您可以随时复制 http 代码并注释掉 flush
。就是这个:
https://core.tcl-lang.org/tcl/artifact/d9f8dc4bd7211a37?ln=1463
第 1463 行:flush $sock
页面顶部有一个 Download
button/link 用于该文件的确切版本(它与您的 Tcl 版本中的版本相比只有很小的变化,并且应该兼容,前提是您source
在执行任何 package require
调用之前显式文件)。
我正在使用 ::http::geturl -query
从 rPi 向 ESP8266(第 3 方商业设备)发出带有小 json 负载的 HTTP POST 请求。它在通过 eth0 发送时有效,但在通过 wlan0 发送时失败。 tcpdump 显示通过 eth0 发送,消息作为单个数据包发送,但是当通过 wlan0 发送时,有效负载从 headers 中拆分并在第二个数据包中发送。 ESP8266 很可能是由于其数据包接收器的实现过于简单 and/or http 服务器似乎无法处理这种拆分。它在收到包含 headers 的数据包后发出 200 OK
响应,并且不处理请求的有效负载部分。
实验性地,我编写了由 ::http::geturl 发送的相同请求消息文本,并使用 nc
通过 wlan0 发送它;它作为单个数据包发送,并被 ESP8266 成功处理。
有没有人碰巧知道为什么使用 ::http 通过 wlan0 发送请求会以这个拆分消息结束,如果可以采取任何措施来防止它发生怎么办?
代码片段:
set s [::http::geturl http://$ip/con?com=cli -query $data -type application/json]
set r [::http::ncode $s]
::http::cleanup $s
Raspbian 软件包版本:
tcl8.6 8.6.9+dfsg-2
tcllib 1.19-dfsg-2
tcl_platform(engine) = Tcl
tcl_platform(machine) = armv7l
tcl_platform(os) = Linux
tcl_platform(osVersion) = 5.4.79-v7+
$ ifconfig wlan0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.101 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::ed38:71ab:13af:ae30 prefixlen 64 scopeid 0x20<link>
ether b8:27:eb:26:bf:94 txqueuelen 1000 (Ethernet)
来自/proc/cpuinfo
:
Hardware : BCM2835
Revision : a020d3
Model : Raspberry Pi 3 Model B Plus Rev 1.3
$ uname -a
Linux raspberrypi 5.4.79-v7+ #1373 SMP Mon Nov 23 13:22:33 GMT 2020 armv7l GNU/Linux
Tcl 的 http 包在写入 headers 和 [=33= 之间将 headers 刷新到套接字(即执行实际的 write()
/send()
) ] 的查询。对于 HTTP 服务器的任何正确实现,这都很好……但您没有使用它。出于某种原因,OS 内核中的 wlan 和 eth drivers 对于如何处理这种情况有不同的策略,eth driver 决定在发送前稍等片刻; Tcl 绝对不会配置套接字的这方面,保持系统默认值。 (我不知道如何配置 OS 默认值。)
您可以随时复制 http 代码并注释掉 flush
。就是这个:
https://core.tcl-lang.org/tcl/artifact/d9f8dc4bd7211a37?ln=1463
第 1463 行:
flush $sock
页面顶部有一个 Download
button/link 用于该文件的确切版本(它与您的 Tcl 版本中的版本相比只有很小的变化,并且应该兼容,前提是您source
在执行任何 package require
调用之前显式文件)。