Netty確實是一個很棒的框架，提供了構(gòu)建高性能HTTP服務器所需的所有功能。 令人高興的是，幾乎所有東西都是開箱即用的，只是必須以正確的方式組合在一起。 內(nèi)容壓縮 （gzip或deflate）也不例外。 但是，在壓縮靜態(tài)內(nèi)容時，我跌跌撞撞了好幾次，然后一切才能按預期進行：

基于netty提供的http / file示例，我習慣于采用以下方法來提供靜態(tài)文件（與netty 3.6.6中使用的相同）：

RandomAccessFile raf = new RandomAccessFile(file, "r"); HttpResponse response = new DefaultHttpResponse(HTTP_1_1, OK); ctx.write(response);if (useSendFile) {ctx.write(new DefaultFileRegion(raf.getChannel(), 0, fileLength)); } else {ctx.write(new ChunkedFile(raf, 0, fileLength, 8192)); }

但是，一旦我將HttpContentCompressor添加到管道中，Firefox就會失敗，并顯示諸如“無效的內(nèi)容編碼”之類的消息。

事實證明， HttpContentCompressor希望將HttpContent對象作為輸入塊進行壓縮。 但是， ChunkedWriteHandler直接將ByteBufs發(fā)送到下游。 同時發(fā)送FileRegion （useSendFile = true）會使內(nèi)容壓縮程序不受影響。

為了克服此問題，我創(chuàng)建了一個名為ChunkedInputAdapter的類，該類采用ChunkedInput <ByteBuf>并表示ChunkedInput <HttpContent> 。 但是，兩件事仍然不能令人滿意：第一，仍然不能使用FileRegions和零復制功能 ，第二，已經(jīng)壓縮的文件（如JPEG）將再次被壓縮。 因此，我使用名為SmartContentCompressor的類對HttpContentCompressor進行了子處理。 此類檢查是否存在標頭“ Content-Encoding：Identity ”或特定的內(nèi)容類型或小于1 kB的內(nèi)容長度 。 在這種情況下，將繞過內(nèi)容壓縮。

使用此組合可以同時使用內(nèi)容壓縮（如果有用）和零復制功能（如果文件已經(jīng)壓縮）。

上面提到的所有資源都是根據(jù)MIT許可和S IRIUS框架的一部分開源的 。

參考： Andy的軟件工程專欄博客中的JCG合作伙伴 Andreas Haufler從netty 4中實現(xiàn)了HTTP內(nèi)容壓縮 。

翻譯自: https://www.javacodegeeks.com/2014/01/making-http-content-compression-work-in-netty-4.html

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的使Netty 4中的HTTP内容压缩工作的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。