InternetOpenUrl仅在下载整个HTTP响应后返回

Question

我正在使用WinINET编写下载文件实用程序，并注意到（特别是在大量下载时），WinINET InternetOpenUrl()调用仅在下载完整个HTTP响应后才会返回。

我通过使用Charles代理工具以及使用WireShark确认了这一点，并注意到下载完全完成，然后WinINET通知我的代码。

一些简化（同步）​​代码：

hInt = InternetOpen(USER_AGENT_NAME, INTERNET_OPEN_TYPE_PRECONFIG, 
                    NULL, NULL, 0);
DWORD dwRequestFlags = INTERNET_FLAG_NO_UI   // no UI please
            |INTERNET_FLAG_NO_AUTH           // don't authenticate
            |INTERNET_FLAG_PRAGMA_NOCACHE    // do not try the cache or proxy
            |INTERNET_FLAG_NO_CACHE_WRITE;   // don't add this to the IE cache

hUrl = InternetOpenUrl(hInt, szURL, NULL, 0, dwRequestFlags, NULL);
if (hUrl)
{
  // <only gets here after entire download is complete>

  InternetCloseHandle(hUrl);
}
InternetCloseHandle(hInt);

文档建议它发送请求，并处理响应的标头（未完成下载），然后您需要运行InternetReadFile()循环，直到它返回TRUE，dwNumberOfBytesRead为0。

  

来自MSDN
   InternetOpenUrl Function： InternetOpenUrl函数解析URL字符串，建立与服务器的连接， 准备 以下载由URL。然后，应用程序可以使用InternetReadFile [...]来检索URL数据。

     

InternetReadFile Function   为了确保检索所有数据，应用程序必须继续调用InternetReadFile函数，直到函数返回TRUE并且lpdwNumberOfBytesRead参数等于零。

我也尝试过使用异步方法，并注意到同样的事情。具体来说，INTERNET_STATUS_RESPONSE_RECEIVED仅在下载完成后发送到已注册的回调方法。这意味着我的客户端只能在下载完成后才能开始访问数据。

与此类似，我实现了一个使用WinHttp库的版本，并注意到完全相同的结果。

这在超时方面会让事情变得棘手。如果下载超过超时（默认值为30秒），InternetOpenUrl()将失败。

所以我有两个问题：

如果这是WinInet和WinHttp库的预期行为，为什么文档建议循环InternetReadFile()调用，为什么不只是读取整个缓冲区（在所有WinINET已经存在之后）？

我理解提供这种功能，因为你并不总是想分配150MB的内存块，但提供的借口是你不知道有多少数据可用......但是WinINET已经完成了下载。

为什么让它看起来非常像recv()方法，如果它只是对临时文件或IE缓存中的文件（或更糟糕的，浪费的内存块）的抽象？

我应该将超时长度设置为什么？如果我不知道数据在超时之前有多大，那么我该如何决定将超时值设置为什么？

这是预期的行为吗？如果是这样，有什么方法可以在流式传输时获取数据？

在慢速连接或大文件上，可以想象在整个下载完成之前可以对数据进行大量工作。在经典的Berkley套接字重新实现HTTP的过程中，循环遍历recv()调用将为我提供数据，因为它最终需要。

是的我可以使用简单的套接字重写一个实现，但我宁愿不必浪费时间来支持整个HTTP规范和SSL加密，更不用说WinINET中的代理支持了。

Answer 1

我知道回答你自己的问题可能不礼貌，但我相信我找出了问题所在。

重新启动后（自动更新中浪费了很多很多很多分钟）我再次尝试，并遇到了同样的问题，但我接受了Alex K.和JJ的评论建议这不是预期的行为，并开始调查可能会干扰的机器上运行的软件。

在许多应用程序被终止，许多服务被关闭后，我偶然发现了一个我真的希望不会产生这种效果的服务，但确实如此。

我关闭了“卡巴斯基实验室网络代理”，嘿嘿，InternetOpenUrl在下载HTTP响应开始后大约2秒后返回。我会立即更喜欢，但75秒下载中的第二或第二次至少会给WinINET时间来处理标题并进行它可能需要的任何预处理。

事实证明，如果我不从InternetReadFile（）读取数据，下载永远不会完成（通过Charles看到），暗示（希望）InternetReadFile（）确实是recv（）调用的包装器（正如我所料）。

连续重新启用和禁用网络代理服务验证了此发现。我想以某种方式最终证明（或反驳）这一点。

事实证明，我的（读取：IT安全部门）反病毒选择及其拦截 - 所有网络层通信保护似乎是问题的原因。