HTTP：在 200 OK 状态码后回复期间出错答案

【问题标题】：HTTP: error during reply after 200 OK status codeHTTP：在 200 OK 状态码后回复期间出错
【发布时间】：2013-05-20 09:03:16
【问题描述】：

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

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

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

我只能想到一个解决方案：关闭socket，但并不完美：它破坏了keep-alive特性，并且没有给客户端明确的错误解释。

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

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

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

【问题讨论】：

有一个Content-Length头，客户端应该知道它应该接收多少数据。想不出任何其他方式，但我承认我从未检查过文件传输后是否发生某事，我不会知道“传输结束”http标头。我敢打赌服务器无论如何都不关心，它是HTTP客户端的业务来验证，毕竟它是最初请求资源的客户端。
知道在发送 200 之前你有内容。是的，缓冲会消耗更多资源（主要是内存），但可以解决这些问题。多个GB 对我的尖叫http 可能是不合适的传输方式......
@Piotr Wadas：如果我们事先不知道回复大小，则无法返回 Content-Length 标头。为特定目的而存在分块传输编码，但似乎没有提供一种方式来表示“现在有错误”。
@Wrikken：确实，HTTP 似乎不是我需要的完美答案，但它仍然是最接近的。 HTTP 是新的 TCP/IP...

【解决方案1】：

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

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

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

我看到的问题是：

【讨论】：

【解决方案2】：

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

【讨论】：