如果我的HTTP服务器获得带有“Connection:keep-alive”标头的HTTP / 1.0请求,那么客户是否理解“Transfer-Encoding:chunked”是否公平?
本质上,我正在尝试决定是否尊重HTTP / 1.0客户端的“Connection:keep-alive”标头 . 如果我确实尊重它,那么我必须使用chunked编码进行回复,因为我无法缓冲整个回复以便计算Content-Length标头 .
如果期望请求“Connection:keep-alive”的HTTP / 1.0客户端也理解分块编码是不安全的,那么我将不得不在每次回复后关闭连接 . (或者我错过了什么?)
3 回答
这是一个明确的“号”从规范中引用:
绝对不是,因为
Transfer-Encoding
仅在HTTP 1.1中 . 根据您的情况,我认为您不能真正支持HTTP 1.0客户端的Connection: keep-alive
标头(对于您的用例,它实际上只是一个优化 .HTTP 1.0中不能进行分块传输编码 . 具有分块传输编码的保持活动请求实际上是HTTP 1.0和1.1之间的定义差异之一 .
为了使服务器能够使用并非所有客户端都支持的功能,如保持活动或分块传输编码,它必须在开始响应之前知道客户端与该功能兼容,因为没有正在进行的初始请求后客户端和服务器之间的双向通信 .
在HTTP 1.0中可以支持Keep-alive本身,因为客户端可以在请求中包含Keep-Alive标头,向服务器指示客户端支持它 .
HTTP 1.0客户端没有确定的方法来指示它们支持分块传输编码,因此服务器无法向HTTP 1.0请求发送分块响应 . 如果您要向不理解它的客户端发送分块响应,客户端将收到垃圾 .
当HTTP 1.0使用keep-alive时,它没有分块传输编码 .
如果服务器在开始发送响应之前不知道响应的内容长度,则服务器只会禁用该响应的保持活动状态 . 服务器并不强制要求每个响应都是保持活动响应 .
在实践中,客户端仍然可以发送keep-alive头,因此即使服务器仅支持HTTP 1.0,它也可以使用keep-alive . 如果服务器支持HTTP 1.1或更高版本,则将忽略该标头,并且HTTP / 1.1协议指示符优先 . 注意:我认为今天的服务器很少支持HTTP 1.1或更高版本,但仍然支持keep-alive,所以发送它很少有用 .