什么导致来自WinHttpSendRequest的间歇性SEC_E_BUFFER_TOO_SMALL错误？

我有一个工具，它执行HTTP S POST命令针对具有相同标题，相同帖子主体等的相同URL进行多次迭代。什么导致来自WinHttpSendRequest的间歇性SEC_E_BUFFER_TOO_SMALL错误？

我碰到的是，对于某些测试人员来说，WinHttpSendRequest（）函数经常失败，随后对GetLastError（）的调用返回记录在这里的SEC_E_BUFFER_TOO_SMALL（0x80090321）：COM Error Codes (Security and Setup)。

这不是WinHttpSendRequest（）记录的错误代码，相当广泛的谷歌搜索没有发现任何东西。

我有四重检查，我提供的输入WinHttpSendRequest（）是正确和有效的，这些输入连续工作数万次......直到它没有。

我无法提供MVCE，但根据此处提供的假设，我正在寻找返回错误代码的任何可能的原因。

2016-08-03 qexyn

请发表编码。 –

“我无法提供MVCE”（最小可验证代码示例）。 – qexyn

由于您正在进行**安全** HTTP请求，并且正在收到**安全**错误，所以很可能“WinHttpSendRequest（）”本身在内部向其使用的安全API内部提供的数据缓冲区不足加密HTTP流量。这可能不是你的错。虽然很难说肯定，因为你还没有显示任何代码.. –

我被某人离线提供了一个答案，并且发现它很有趣。

在使用RSA + ECDHE的TLS 1.2中发生的密钥交换期间，ECDHE的256字节（2048位）公共模数整数随机生成，因此偶尔会有高位字节为零。在这种情况下，正在使用的服务器（某些带有OpenSSL的Linux机箱，不知道发行版或任何版本的任何内容）将使用256字节发送整数。

WinHTTP代码接收公共模数整数在其稍短的形式显然不能正确处理。值得注意的是，我还没有看到这个问题在所有软件更新的Windows 7上重现，但在Windows 8上经常看到它（Windows 10尚未测试）。

在微软边缘此错误的报告证实了相同的行为，只需用1024位模数，而不是2048，但可能是同一个问题：

但是，它确实让我怀疑如果OpenSSL应该填充整数。我没有找到实际的规格，看看在这种情况下允许的行为是什么。

2016-08-30 00:24:44 qexyn

回答