webclient Content-Length 产生的bug

ztlchina commented 2 years ago

webclient_shard_position_function 函数里： data_len = webclient_response(session, (void **)&buffer, &resp_len); if(data_len > 0) { start_position += mem_size; //这里应该加data_len, 而不应该加mem_size;

http原始报文：

02:45:44 [281382] D/web: response header:
02:45:44 HTTP/1.1 206 Partial Content
02:45:44 [281483] D/web: Date: Fri, 21 Jan 2022 18:45:44 GMT
02:45:44 [281489] D/web: Server: Apache/2.4.7 (Ubuntu)
02:45:44 [281494] D/web: Last-Modified: Fri, 21 Jan 2022 10:45:18 GMT
02:45:44 [281501] D/web: ETag: "36dc0-5d61550953499"
02:45:44 [281505] D/web: Accept-Ranges: bytes
02:45:44 [281509] D/web: Content-Length: 51  // 请求的是512个字节，这儿返回的是51个字节。 
02:45:44 [281513] D/web: Content-Range: bytes 71680-72191/224704
02:45:44 [281519] D/web: get position handle response(1).

我天，我调了半夜，终于找到http_ota下载大数据crc校验失败的原因了。。。。

xiangxistu commented 2 years ago

02:45:44 [281509] D/web: Content-Length: 51  // 请求的是512个字节，这儿返回的是51个字节。 
02:45:44 [281513] D/web: Content-Range: bytes 71680-72191/224704

这里 72191 - 71680 = 511 ，符合请求 512 字节的含义。为什么这个 Content-Length 是 51 呢，是传输中少了传输了一个字符？

xiangxistu commented 2 years ago

我明白了， AT_Device 在收取数据时，不知怎么就将 512 解析为 51<也许是字符丢失，也许是其他原因>。在后续接收数据时，是以 51 字节大小接收的，并不是以 512 接收；在 webclient 的分片下载中，没有考虑到传输中出现小于 mem_size 大小数据的情况，导致逻辑出现错误。

这个错误的原因首先是，AT 这边解析不知道出现了什么错误，其次是 webclient 的容错能力不强，而且使用真实接收的数据大小更合理。

非常感谢提醒，👍

RT-Thread-packages / at_device

webclient Content-Length 产生的bug #173