[OpenWrt-Devel] [PATCH] uhttpd: serve precompressed files

Sergey Ponomarev stokito at gmail.com
Mon Jun 8 18:38:33 EDT 2020

Follow up on this patch:

1. The patch it was tested and accepted into ArednMesh.org 
<https://www.arednmesh.org/> because they works with distant networks 

The same problem is actual for a regular WiFi networks e.g. trying to 
login into Luci when something wrong with wifi and you want to check 

So speaking about space vs network tradeoff then network may be more 

The patch looks fine but we can add support of other browser supported 
encoders: DEFLATE, LZ4 and Brotli. Also if we requested the compressed 
file itself e.g. /backup.tar.gz then user wants to download the archive 
as is so no need to add Content-Encoding header.

2. There is a patch "uhttpd: add support for gzipped content encoding" 
Message ID 1443738134-5929-2-git-send-email-ak77 at tnode.com 
which makes on the fly encoding. But the patch looks like forgotten but 
I added it's author to CC.

I reviewed it's code and the patch looks good and it can be even 
slightly improved by switching from gzip to raw DEFLATE i.e. gzip 
without header and checksum so more lightweight.

To switch to deflate just need to just negate windowBits param of 
deflateInit2 i.e. instead of `16 | MAX_WBITS` use `-(16 | MAX_WBITS)`.

Anyway precompressing makes sense if use Brotli instead of gzip and this 
may solve the space/network/cpu tradeoff. I checked on my homepage:

  204800 www_homepage.tar          i.e. uncompressed size
    68114 www_homepage.tar.br      assets precompressed with brotli
   70220 www_homepage.tar.xz       as it will be compressed in openwrt image
   68180 www_homepage.tar.br.xz   so precompressed with brotli asset 
takes the same place in openwrt image

Off course sizes still may be better in xz but anyway it looks like we 
can safely precompress the Luci assets.

openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list