沒有傳輸編碼的HTTP流丟失EOF分塊

我使用Netty 4通過HTTP傳輸內容。內容是動態生成的，因此無法提前知道內容長度。我現有的非netty代碼寫入OutputStream，所以我編寫了一個簡單的包裝，圍繞OutputStream寫入並將它們放在ByteBuf中，當它滿了時，它將其寫爲DefaultHttpContent的有效負載。在寫入OutputStream之前，我會發送一個非完整的HttpResponse w/an OK狀態碼。沒有傳輸編碼的HTTP流丟失EOF分塊

當在流上調用close時，我發送本地ByteBuf中未發送的任何內容，然後發送LastHttpContent.EMPTY_LAST_CONTENT。

我用wget看到的是，它獲取所有字節，但隨後坐着等待流的結束。如果我在初始響應中加入了Transfer-Encoding：Chunked頭部，事情就很完美。

我可以看到HttpObjectEncoder中LastHttpContent消息的處理方面的一些差異，這是我在嘗試分塊傳輸頭時提到的。什麼我不清楚的區別是什麼，爲什麼EOF似乎不能發送W/O頭，即使所有的字節發送和我送LastHttpContent.EMPTY_LAST_CONTENT

編輯：

我可以通過對Netty 4示例中的HttpStaticFileServerHandler進行簡單修改來重現此行爲。我正在使用this class發送文件回客戶端，this（需要番石榴）是我的修改channelRead0方法從HttpStaticFileServerHandler而不是設置內容長度&直接寫入文件通道，它複製文件到通道ByteBuffHttpOutputStream其通過DefaultHttpContent發送1MB大塊的輸出，並在close上發送LastHttpContent.EMPTY_LAST_CONTENT。如果我刪除Transfer-Encoding標題的設置：（response.headers().set(Names.TRANSFER_ENCODING, Values.CHUNKED)），那麼使用wget獲取文件永遠不會完成。 afaict，我正確發送流，它看起來像像HttpObjectEncoder應正確處理LastHttpContent，但還沒有EOF。

來源

2013-09-05 Michael

我認爲這只是固定的主人，將是4.0.9.Final

https://github.com/netty/netty/pull/1787

來源

2013-09-06 07:45:48

的部分似乎不是修復它，看到我編輯的問題。 – Michael

我認爲您需要在LastHttpContent寫入後關閉頻道，因爲您沒有設置任何內容長度。 –

我懷疑這樣做會起作用，但是這並不能完全擊敗要求保持連接的客戶端？ – Michael

沒有傳輸編碼的HTTP流丟失EOF分塊

回答

相關問題