HTTP:200 OK状态代码后回复期间出错 [英] HTTP: error during reply after 200 OK status code

查看:1016
本文介绍了HTTP:200 OK状态代码后回复期间出错的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

作为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.

推荐答案

我终于找到了一个可能的解决方案:
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)之后应用的,因此需要大量的重新实现)

    • 客户端(仅在 2010年卷曲中修复的错误例如)

    • 和代理(如果没有正确实施,可能会松散预告片)

    • 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状态代码后回复期间出错的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆