HTTP：发送请求后写入的关闭套接字？

发送请求后，HTTP客户端使用的套接字如何正确关闭？还是必须保持开放（双向）直至收到完整回复？如果是这样，请求体的结束如何由服务器确定？HTTP：发送请求后写入的关闭套接字？

根据http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4，关闭套接字不是请求的选项。这对我来说听起来并不合理 - 如果客户端在关闭其一半的套接字后不尝试传输任何东西，为什么半关闭的TCP连接对服务器来说是个问题？客户端仍然可以接收数据。

在我看来，关闭套接字的写入部分将是让服务器知道请求已完成的一种非常实用的方法。 http://docs.python.org/howto/sockets.html#disconnecting甚至具体提到该用例。

如果这确实是错误的做法，那么有什么选择？我是否总是必须发送“Content-length”或使用分块传输来使服务器正确地找到请求的结尾？这对身体未知长度的请求如何工作？

来源

2012-01-13 lxgr

Transfer-Encoding: chunked专门设计用于发送身体未知长度的数据，用于请求和响应。数据的结束通过接收有效负载大小为0的块来确定。如果您不发送chunked请求，则必须发送Content-Length。

来源

2012-01-13 20:52:06

因此，它是强制性使用分块传输编码或发送一个“Content-Length”标头的请求身体的所有请求？我知道这将是一个明智的做法，但实际上是在标准中的某处指定的吗？ – lxgr 2012-01-13 21:28:24

如果请求具有正文，则必须包含足够的信息以供服务器确定正文的大小。阅读RFC 2616第4.3节（消息体）和4.4（消息长度）。 – 2012-01-13 21:55:15

你说的是这个？：

关闭连接不能用于指示请求主体的结束，因为这将留下任何可能性服务器发回一个响应。

我觉得文中谈论的是全关，你可以做一半（写） - 关闭。我不确定这是一种HTTP编译方式，但我认为大多数服务器都会接受它。

关于第二个问题，简单地使用分块编码：

所有HTTP /接收实体必须接受“分块”传输编码（第3.6节）1.1应用程序，从而允许用于该机构消息长度无法预先确定时的消息。

来源

2012-01-13 19:48:59

是的，这是我所指的段落。所以你会说，做一个半关闭是安全的吗？那就是我所希望的;我不想为简单的HTTP服务器实现分块传输编码。 – lxgr 2012-01-13 21:27:23

好吧，我的经验是，服务器比标准指定的更容忍错误（可能与蹩脚的客户端...）。这听起来像你正在写你的服务器和客户端..在这种情况下，如果你的路径中没有HTTP代理，你可以做任何你想做的事情。这是不是一件好事，但它的工作原理;） – 2012-01-14 11:27:16

HTTP：发送请求后写入的关闭套接字？

回答

相关问题