异常：使用lua-resty-upload/lib/resty/upload.lua lib读区client post上传的数据

njbupt · 2015-10-20T20:47:56+00:00

Hello! 2015-10-20 19:31 GMT+08:00 DeJiang Zhu: > 在 2015年10月20日上午11:27，renyuxiao <reny...@163.com>...

异常：使用lua-resty-upload/lib/resty/upload.lua lib读区client post上传的数据

njbupt

Hi, all && 春哥

我在使用lua-resty-upload/lib/resty/upload.lua lib读区client post上传的数据时，发现了一种异常的case：

Post上传一个4M的文件，每次读区256KB(chunk_size)，发现在读区到某一chunk的时候（非最后一个分片），返回的data size < chunk_size，

这时候按照程序的逻辑，需要再读一次，确认是否数据已经读完了，但是这时候读取返回err: timeout 或者 client aborted；

但是之前我自己测试的时候如果上传过程中中断上传，会立即返回err:client aborted or timeout，是不会出现先 data size < chunk_size 后 err的情况的。

大家有遇到这种异常的情况吗？

谢谢～

agentzh

Hello!

2015-10-20 20:47 GMT+08:00 jun ni:
>      我在使用lua-resty-upload/lib/resty/upload.lua lib读区client
> post上传的数据时，发现了一种异常的case：
>
> Post上传一个4M的文件，每次读区256KB(chunk_size)，发现在读区到某一chunk的时候（非最后一个分片），返回的data size <
> chunk_size，
> 这时候按照程序的逻辑，需要再读一次，确认是否数据已经读完了，但是这时候读取返回err: timeout 或者 client aborted；

cosocket 的 receive() 不同于 BSD socket 的 recv()
函数，前者不读完指定大小的数据是不会提前返回的，即使已经读到一部分数据。你这里的情况很明显是客户端连接上的错误，timeout
即是读超时，client aborted 即是客户端提前断开连接。就这么简单呀。

如果你仍然认为 cosocket 有 bug，请提供一个最小化的完整的用例，以便我们大家可以在本地很方便地复现问题。

Regards,
-agentzh

njbupt

receiveuntil 确实是这样的逻辑，但是从case的结果上看是：读取非最后一个分片时，读到的data size < chunk_size; 但是并不是直接返回err: timeout 或者 client aborted；而是先返回了部分的data，后面我再读取一次时，才返回err。但是刚才上一次部分data却是返回了。。。很奇异，我再看看能不能复现吧，谢谢春哥

在 2015年10月20日星期二 UTC+8下午8:56:48，agentzh写道：

Hello!

2015-10-20 20:47 GMT+08:00 jun ni:
> 我在使用lua-resty-upload/lib/resty/upload.lua lib读区client
> post上传的数据时，发现了一种异常的case：
>
> Post上传一个4M的文件，每次读区256KB(chunk_size)，发现在读区到某一chunk的时候（非最后一个分片），返回的data size <
> chunk_size，
> 这时候按照程序的逻辑，需要再读一次，确认是否数据已经读完了，但是这时候读取返回err: timeout 或者 client aborted；

cosocket 的 receive() 不同于 BSD socket 的 recv()
函数，前者不读完指定大小的数据是不会提前返回的，即使已经读到一部分数据。你这里的情况很明显是客户端连接上的错误，timeout
即是读超时，client aborted 即是客户端提前断开连接。就这么简单呀。

如果你仍然认为 cosocket 有 bug，请提供一个最小化的完整的用例，以便我们大家可以在本地很方便地复现问题。

Regards,
-agentzh

agentzh

Hello!

2015-10-20 21:22 GMT+08:00 jun ni:
> receiveuntil 确实是这样的逻辑，但是从case的结果上看是：读取非最后一个分片时，读到的data size < chunk_size;
> 但是并不是直接返回err: timeout 或者 client
> aborted；而是先返回了部分的data，后面我再读取一次时，才返回err。但是刚才上一次部分data却是返回了。。。很奇异，我再看看能不能复现吧，谢谢春哥
>

和 receive(size) 方法不同，receiveuntil() 返回的迭代器的 size
参数是建议性的，实际返回的数据块大小可能更大一些，也可能更小一些。所以你描述的行为倒也算是正常的行为。引用一下对应的官方文档对
receiveuntil 返回的迭代器的 chunk size 参数的描述：

“Note that, the actual data returned might be a little longer than the
size limit specified by the sizeargument when the boundary pattern has
ambiguity for streaming parsing. Near the boundary of the data stream,
the data string actually returned could also be shorter than the size
limit.”

Regards,
-agentzh

njbupt

问题基本定位了：POST的数据body中含有boundary，读取到中间某个分片的时候，就return了，然后lib是需要将剩余的数据全部读取上来丢弃之，再读取剩余的垃圾数据时，这时候client 断开了连接，所以就出现了上述的err。

麻烦春哥了～！

在 2015年10月21日星期三 UTC+8上午11:06:54，agentzh写道：

Hello!

2015-10-20 21:22 GMT+08:00 jun ni:
> receiveuntil 确实是这样的逻辑，但是从case的结果上看是：读取非最后一个分片时，读到的data size < chunk_size;
> 但是并不是直接返回err: timeout 或者 client
> aborted；而是先返回了部分的data，后面我再读取一次时，才返回err。但是刚才上一次部分data却是返回了。。。很奇异，我再看看能不能复现吧，谢谢春哥
>

和 receive(size) 方法不同，receiveuntil() 返回的迭代器的 size
参数是建议性的，实际返回的数据块大小可能更大一些，也可能更小一些。所以你描述的行为倒也算是正常的行为。引用一下对应的官方文档对
receiveuntil 返回的迭代器的 chunk size 参数的描述：

“Note that, the actual data returned might be a little longer than the
size limit specified by the sizeargument when the boundary pattern has
ambiguity for streaming parsing. Near the boundary of the data stream,
the data string actually returned could also be shorter than the size
limit.”

Regards,
-agentzh