其他分享
首页 > 其他分享> > cpprestsdk有bug.

cpprestsdk有bug.

作者:互联网

好不容易将cpprestsdk移植到MinGW,并编译通过,出于安全还是先将samples还有tests测试一下是否正常。

用samples/blackjack一测试就出现奇葩现象,server一端会时不时出现一次response中,两次发送headers,并且没有任何征兆。

当用gdb调试,break+command,断点打印浏览时,却从没有发生过一次奇怪现象。毕竟断点使得程序更加慢而且更加偏向串行的方式在运行。

下面是现象的抓包

 

 

 

 

正常发两次包,第一次72字节header,第二次222字节content。

 

 异常也发了两次包,第一次72字节headers,第二次294 (72 + 222 )字节 headers + contents。

 分析代码cpprestsdk/Release/src/http/http_server_asio.cpp,发送是由m_write,m_write_size两成员控制。

但搜索下来,只有一处赋值,“m_write = m_write_size = 0; ”,只能唯有用watch+command来观察。

观察点分别是 14: m_write_size, 15: m_write。

 m_write_size 被修改触发断点。

 然后序列化headers,并发送。

 

 m_write 被修改触发断点。

 

 发现 m_write_size 在http_headers.match()匹配content_length字段同时赋值,无语。m_write赋值的地方也无语,分析代码根本就不能搜索到。

从代码分析得到流程。

1. http_response的组成,http_headers一个字典容器,body是一个instream,还有一个用于发送的streambuf。

2. 我们的处理代码先向body写入内容,然后调用reply。

3. http_headers先序列化到streambuf,并发送第一个数据包。

4. 完成后将body写入streambuf,并发送第二个数据包。

正常跟异常两种情况下,第一次发包正常,第二次发包有差。原因可能是streambuf,没有清数据。

 

 asio在取出iocp事件后,是先清streambuf数据,然后才会去回调handler,但为什么还要有例外不正常的情况发生呢。原因是cpprestsdk开发小组的成员在偷懒了。(小组压根就不打算移植到mingw,http_server的asio实现版只针对非windows,windows开发环境下默认使用httpsys实现版,所以就不会去考虑asio可能运行在winiocp的情况了)。

 

 没有去理会bytes_transferred,直接忽略, 回调lambda [=](error_code& ec, size_t)。但是winiocp有一种情况,就是WriteEx时马上成功了,没有发生BLOCKING。投递出去的iocp overlapped,将会是没有错误,同时bytes_transferred也为0。这样一来,asio就只会consume(0),根本没有清理数据,数据残留了下来,后续的发送就是乱套的。这种情况下,就必须自己去做处理。

 

标签:asio,http,cpprestsdk,write,headers,streambuf,bug,size
来源: https://www.cnblogs.com/bbqzsl/p/13127265.html