[Libwebsockets] serving compressed http response from a zip archive
andy at warmcat.com
Sun Feb 12 02:00:16 CET 2017
On 12 February 2017 05:23:20 GMT+08:00, Per Bothner <per at bothner.com> wrote:
>(http://domterm.org). The "ldomterm" application is the combination of
>DomTerm + libwebsockets + application code (derived from ttyd), which
>optionally starts up a window in a specified browser.
Sounds very cool.
>It's working quite well, but for various practical reasons it might
>make sense to
>put the "resources' (html + js + css) in a zip archive. It seems
>to mmap the zip file, and then use JUnzip
>decompress the requested file and send the data with lws_write_http.
>What would be really interesting if we could send the compressed data
>and let the browser decompress it. Most browsers accept gzip
>and creating a gzip result from a deflate-compressed zip entry should
>just a matter of sending a gzip header, followed by the raw compressed
>followed by the gzip tail (using the crc32 checksum present in the zip
>Does this make sense? Has anyone tried something similar?
I have not done it, but I think it should be workable.
The main thing that will help stitch this in is lws file serving arrangements have a thin VFS between the code doing the serving and the filesystem, via a file_ops type struct of callbacks
You can set your own file ops callback which provide normal posix semantics to open / seek / read / close that hides the work you're doing underneath. The main things missing are
- someone has to look at Accept-Encoding and see gzip, deflate to 'enable' this, if missing your code has to inflate it and not send compressed because peer can't handle it
- someone has to send Content-Encoding: gzip,deflate if the url falls into a part of the namespace that can be served compressed
- in the case you need to mix compressed and uncompressed (generated, say) content with no clear url namespace delineation, and no dynamic compression support on precompressed support, a way to inform lws the individual file is compressed or not
How does it sound if we add these to lws, so it
- checks Accept-Encoding and passes a flag to .open() indicating if the peer could handle gzip compressed
- add a pointer to .open that may be written to with returned flags indicating, eg, content is gzip-compressed
- if the suitable return flag was set above and Accept-Encoding matched it, lws generic file serving will deal with appending Content-Encoding
Sent from my Android device with K-9 Mail. Please excuse my brevity.
More information about the Libwebsockets