如何使用 Indy TIdTCPClient 实例从包含响应正文的 Web 服务器检索完整的 HTTP 响应？答案

【问题标题】：How do I retrieve a complete HTTP response from a web server including response body using an Indy TIdTCPClient instance?如何使用 Indy TIdTCPClient 实例从包含响应正文的 Web 服务器检索完整的 HTTP 响应？
【发布时间】：2012-06-07 16:13:28
【问题描述】：

我有一个使用 Indy TIdTCPClient 实例与 Web 服务器通信的 Delphi 6 应用程序。我不直接使用 HTTP 客户端的原因是因为服务器是图像流服务器，它使用 same 套接字连接来接收开始流式传输的命令，就像它开始“推”回图像一样给你。换句话说，在您向它发送一个典型的 HTTP POST 请求后，它会回复一个 HTTP 响应，然后立即开始发送 JPEG 图像流。

我已经知道如何制作正确的 POST 请求并使用 TIdTCPClient WriteBuffer() 方法发送它，然后使用 ReadBuffer() 方法接收回复数据。我想做的是发送一个 POST 请求，然后让 Indy 等待一个典型的 HTTP 响应，包括如果有 Content-Length 标头变量，则检索响应正文中的所有字节.我当然希望它保留接收队列中的 HTTP 响应之后可能堆积的 JPEG 帧，直到我开始请求它们（也就是说，我不希望它在 HTTP 响应中包含任何 JPEG 帧我的流媒体请求命令，直到我使用连续的读取调用请求它们）。

有没有一种方法可以在 TIdTCPClient 上调用，该方法将完全检索带有正文内容的典型 HTTP 响应，仅此而已？我考虑过使用 SendCmd() 并检查 LastCmdResult 属性（类型：TIdRFCReply）以获取响应，但我无法从Indy 文档是否也检索响应正文内容如果有一个 Content-Length 标头变量作为它返回的响应的一部分，我也无法判断它是否在响应后离开接收队列的其余部分完好无损。

在您发出 HTTP 请求以开始流式传输后立即推出 JPEG 帧流的 HTTP Web 服务器完成这种混合模式交互的最佳方式是什么？

另外，如果有一种巧妙的方法让 Indy 使用 JPEG 帧 WINBONDBOUDARY 分隔字符串分割帧，而不是累积数据块并自己解析它们，请分享该技术。

【问题讨论】：

你为什么直接使用TIdTCPClient而不是TIdHTTP呢？ TIdHTTP 为您处理响应读取，并且可以使用 TIdHTTP 读取流数据，但需要做一些额外的工作（它本身不支持流数据）。
@RemyLebeau - 我必须在一个紧密的循环中向机器人发送一个重复的 HTTP 命令。如果命令之间有最轻微的停顿，电机就会减速，并且不可能实现平稳运动。我最初确实使用了 TIdHTTP 组件，以及您在另一篇文章中给我的所有保持活动提示，但它的响应速度不够快。有时它会立即返回，有时它需要 200-500 甚至 3000 额外的毫秒才能返回响应。这一切都在后台线程上。自从我切换到 TIdTCPClient 并自己处理 HTTP 握手后，所有这些问题都消失了。
如果您使用的是最新版本的 Indy，TIdHTTP.HTTPOptions 属性不久前更新了一个新的 hoWaitForUnexpectedData 标志来处理一些响应延迟，只需确保该标志已禁用。
@RemyLebeau - 我正在使用 Indy 9，因为我无法使用 Delphi 6 成功编译较新的版本。我只是通过 Indy 9 源代码进行了全文搜索，但找不到 hoWaitForUnexpectedData标志，所以我猜它在较新的版本中。幸运的是，我的代码现在正在使用 IdTCPClient 实例。
Indy 9 和 10 都支持 D6。如果您在 D6 上安装 Indy 10 时遇到问题，请随时发布有关该问题的新问题，或在 Embarcadero 或 Indy 论坛中提问。 hoWaitForUnexpectedData 仅在 Indy 10 中，并且是最近添加的。 Indy 10 和 Indy 9 的早期版本在 TIdHTTP 中包含一些硬编码延迟，以处理一些错误的 HTTP 服务器，这些服务器在不应该发送数据时发送数据，因此延迟用于检查意外数据是否真的出现插座。

标签： delphi http sockets indy rfc

【解决方案1】：

正确读取 HTTP 响应的方法是首先逐行读取以 CRLF 分隔的响应标头，直到遇到空行，即 CRLF+CRLF 序列，然后您可以使用这些标头来决定如何读取剩余的响应数据。标头不仅会告诉您正在发送哪种类型的流（通过Content-Type 标头），还会告诉您数据是如何被构建的（Content-Length、Transfer-Encoding: chunked、特定于特定Content-Type 的内容等)。

要接收标头，您可以使用连接的Capture() 方法，将其ADelim 参数设置为空字符串。

之后如何读取剩余数据取决于流的实际格式/框架。在不确切知道您正在接收什么样的流的情况下，没有办法建议您如何最好地阅读它，因为 HTTP 服务器使用了几种不同类型的流协议，其中大多数都没有标准化。提供该信息，然后我/我们可以向您展示如何使用 Indy 实现它。

您不能使用SendCmd()，因为 HTTP 协议没有以与该方法兼容的方式格式化其响应。

【讨论】：

响应流要么是简单的仅标头响应，要么是具有长度由 Content-Length 标头变量指定的正文的响应。我只是读取该变量（如果它存在），然后对那么多字节进行阻塞读取。目前工作正常。
阅读RFC 2616 Section 4.4，了解所有确定响应正文是否存在以及如何正确阅读的官方规则。