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
https://github.com/aredn/aredn_ar71xx/pull/276.
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
connectivity.
So speaking about space vs network tradeoff then network may be more
important.
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-a...@tnode.com
https://patchwork.ozlabs.org/project/openwrt/patch/1443738134-5929-2-git-send-email-a...@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@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
