问题描述
作为HTTP 1.1服务器，我使用200 OK状态代码回复GET请求，然后开始将数据发送到客户端。
在此发送过程中，发生错误，我无法完成。
As an HTTP 1.1 server, I reply to a GET request with 200 OK status code, then start sending the data to the client.During this send, an error occurs, and I cannot finish.
我无法发送新的状态代码，因为最终状态代码已经发送。
I cannot send a new status code as a final status code has already been sent.
我应该如何让客户知道发生错误并且我无法继续处理此HTTP请求？
我只能想到一个解决方案：关闭套接字，但它并不完美：它打破了keep-alive功能，并且没有给客户端错误的明确解释。
I can think of only one solution: close the socket, but it's not perfect: it breaks the keep-alive feature, and no clear explanation of the error is given to the client.
HTTP标准似乎假设服务器在开始回复之前已经确切知道要回复的内容。
但情况并非总是如此。
示例：
我从磁盘返回一个非常大的文件（几GB），在读取文件期间的某个时刻出现IO错误。
大数据库转储的相同示例。
The HTTP standard seems to suppose that the server already knows exactly what to reply before it starts replying.But this is not always the case.Examples:I return a very large file (several GB) from disk, and I get an IO error at some point during the reading of the file.Same example with a large DB dump.
我无法在内存中构建我的整个响应然后发送它。
I cannot construct my whole response in memory then send it.
HTTP 1.1标准有助于使用分块传输编码：在开始发送回复之前，我甚至不需要知道最终大小。
所以这些用法不会从HTTP 1.1中排除。
The HTTP 1.1 standard helps for such usage with the chunked transfer encoding: I don't even need to know the final size before starting to send the reply.So these usage are not excluded from HTTP 1.1.
推荐答案
我终于找到了一个可能的解决方案：
。
I finally found a possible solution for this:HTTP 1.1 Trailer headers.
在分块编码体中，HTTP 1.1允许发送者以标题块的形式在最后一个（空）块之后添加数据。
该规范暗示了一些用例，例如在机身上运行md5计算，并将其发送到正文之后，以便客户端可以检查其完整性。
In chunked encoded bodies, HTTP 1.1 allows the sender to add data after the last (empty) chunk, in the form of a block of headers.The specification hints some use-cases like computing on the fly a md5 of the body, and send it after the body so the client can check its integrity.
我认为它可以用于错误报告，即使我没有找到任何关于这种用法的信息。
I think it could be used for error reporting, even if I haven't found anything about this kind of usage.
我看到的问题是：
- 这需要使用分块编码（但这不是什么大问题）
- 预告片支持可能非常低：
- 服务器端（可以通过手动创建分块编码来绕过它，但由于它是在内容编码（gzip）之后应用的，因此需要大量的重新实现）
- 客户端（仅在例如）
- 和代理（如果没有正确实施，可能会松散预告片）
- this requires using chunked encoding (but it's not much of an issue)
- trailers support is probably very low:
- server-side (it could be bypassed by manually creating the chunked encoding, but since it's applied after the content-encoding (gzip), it would require a lot of reimplementation)
- client-side (bugs fixed only in 2010 in curl for example)
- and on proxies (that could then loose the trailers if not properly implemented)
这篇关于HTTP：200 OK状态代码后回复期间出错的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！