Netty 没有传输编码分块的HTTP流中缺少EOF

我正在使用Netty 4通过HTTP传输内容。内容是动态生成的，因此无法提前知道内容长度。我现有的非netty代码写入一个

OutputStream

，因此我在一个

OutputStream

周围编写了一个简单的包装器，它接受写入并将它们放入一个

ByteBuf

，当它满了时，它将其作为

DefaultHttpContent

的有效负载写入。在写入

输出流之前，我会发送一个非完整的
HttpResponse
w/an
OK
状态代码

在流上调用close时，我发送本地ByteBuf中尚未发送的内容，然后
LastHttpContent.EMPTY\u LAST\u CONTENT

我在wget中看到的是，它获取所有字节，然后坐在那里等待流的结束。如果我将Transfer-Encoding:Chunked头放在初始响应中，事情就会完美地工作

我可以在
HttpObjectEncoder
中看到对最后一条httpcontent消息的处理上的一些差异，这就是我尝试分块传输头的原因。我不清楚的是区别是什么，以及为什么EOF似乎没有通过标头发送，即使发送了所有字节，并且我正在发送
LastHttpContent.EMPTY\u LAST\u CONTENT

编辑：

我可以通过对Netty 4示例中的
HttpStaticFileServerHandler
进行简单修改来重现这种行为。我正在使用将文件发送回客户端，（需要Guava）是我从
HttpStaticFileServerHandler
修改的
channelRead0
方法，它不是设置内容长度并将文件直接写入频道，它通过
ByteBuffHttpOutStream
将文件复制到通道，该通道通过
DefaultHttpContent
发送1 MB的输出块，并在
close
上发送
LastHttpContent.EMPTY\u LAST\u CONTENT
。如果我删除
传输编码
头的设置：（
response.headers（）.set（Names.Transfer\u Encoding，Values.CHUNKED）
），那么使用wget获取文件永远不会完成。afaict，我正确地发送了流，看起来
HttpObjectEncoder
应该正确地处理
LastHttpContent
，但是没有EOF。
我认为这在master中已经修复，将成为4.0.9.Final的一部分

我认为您需要在编写最后一个HttpContent之后关闭频道，因为您没有设置任何内容长度。我怀疑这会起作用，但这不会完全阻止客户端请求保持活动连接吗？除非您指定内容长度并且不使用分块编码，知道内容结束的唯一方法是连接结束。所以保持活动状态和将内容流回到客户端是互斥的吗？