[Libwebsockets] serving compressed http response from a zip archive

Andy Green andy at warmcat.com
Fri Mar 3 03:07:19 CET 2017



On 1 March 2017 08:06:53 GMT+08:00, Per Bothner <per at bothner.com> wrote:
>If you want to include zip archive (or gzip file) support in
>libwebsockets,
>I think the code in DomTerm is clean enough that it can be used with
>modest changes.
>
>The source is in the directory:
>https://github.com/PerBothner/DomTerm/tree/master/lws-term

Thanks a lot... I started looking at this.

So far I imported junzip into lws and now I will be looking at how to merge the zip fops pieces in a reusable way.

-Andy

>Specifically,:
>- The files junzip.h and junzip.c handle the
>actual parsing and seeking in the zip archive.
>For simplicity and performance, it assumes the zip
>archive is in memory. DomTerm mmaps the file in,
>but it would be a trivial change to handle a literal data buffer,
>as created by xxd --include.
>The jzReadData function decompresses a file entry; it is not called
>if the response can be compressed.
>- The io.c file provides the "fops" wrapper.  It determines
>if the data can be sent uncompressed as-is: If so,
>it copies it out of the zip file; otherwise it calls jzReadData.
>- The file http.c is http-server part of DomTerm.
>It just adds a "domterm:" prefix to the path.
>
>It seems that rather than keying off a "domterm:" prefix
>we should be using a struct lws_http_mount.  I haven't tried that.
>It seems what is missing is a pointer from a lws_http_mount instance
>to either a lws_plat_file_ops or at least a mount-specific open method.
>Would it make sense to add a field in struct lws_http_mount to
>either a lws_plat_file_op table or just an open function? Or is
>there a better way to do it?

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.



More information about the Libwebsockets mailing list