10

作为 HTTP 1.1 服务器，我用 200 OK 状态码回复 GET 请求，然后开始向客户端发送数据。在此发送期间，发生错误，我无法完成。

我无法发送新的状态代码，因为最终状态代码已经发送。

我应该如何让客户端知道发生了错误并且我无法继续此 HTTP 请求？

我只能想到一个解决方案：关闭套接字，但这并不完美：它破坏了保持活动功能，并且没有向客户端给出错误的明确解释。

HTTP 标准似乎假设服务器在开始回复之前已经确切地知道要回复什么。但情况并非总是如此。示例：我从磁盘返回一个非常大的文件（几 GB），并且在读取文件期间的某个时间点出现 IO 错误。与大型数据库转储相同的示例。

我无法在内存中构建我的整个响应然后发送它。

HTTP 1.1 标准通过分块传输编码帮助这种用法：在开始发送回复之前，我什至不需要知道最终大小。所以这些用法不排除在 HTTP 1.1 之外。

4

2 回答 2

3

我终于找到了一个可能的解决方案： HTTP 1.1 Trailer headers。

在分块编码的正文中，HTTP 1.1 允许发送者在最后一个（空）块之后以标头块的形式添加数据。该规范暗示了一些用例，例如动态计算主体的 md5，并将其发送到主体之后，以便客户端可以检查其完整性。

我认为它可以用于错误报告，即使我还没有发现任何关于这种用法的信息。

我看到的问题是：

  • 这需要使用分块编码（但这不是什么大问题）
  • 拖车支持可能非常低：
  • 服务器端（可以通过手动创建分块编码来绕过它，但由于它是在内容编码（gzip）之后应用的，因此需要大量重新实现）
  • 客户端（例如，仅在2010 年在 curl中修复的错误）
  • 和代理（如果没有正确实施，可能会丢失拖车）
于 2014-02-24T14:56:40.680 回答
2

我已经推送了类似的问题来回答，所以在这里你可以发现没有解决方案：

如何在以 200 OK 开始的响应期间判断服务器有问题。优雅地失败

于 2013-10-23T14:28:03.030 回答