[Libwebsockets] serving compressed http response from a zip archive

Denis Osvald denis.osvald at sartura.hr
Mon Feb 13 11:31:37 CET 2017

Hello everybody,

I'm using lws to make a web UI from a system with possibly constrained
disk space. The resources (html, js, css) are stored on disk gzipped
individually and content-encoding: gzip is added for such files when
served by lws.

Since this has (so far) been a special case not supported by lws,
currently I'm handling this case "manually" by bypassing lws
file-serving logic.

I haven't looked at the recent changes in master, but do you think this
use case (where GET /file.js ends up with /file.js.gz +
content-encoding: gzip) would be resolved / made easier by new lws APIs?

If not (or if I have more special-case requirements), what is the best
way to "bypass" lws's VFS / file-serving logic? Currently I'm doing it
as a hack by making a mount of "/dev/null" which makes lws code fall
through to my protocol handler, where I can handle special cases like
this. It works alright this way.


Denis Osvald

On 2017-02-12 11:54, Andy Green wrote:
> On 02/12/2017 10:27 AM, Per Bothner wrote:
>> On 02/11/2017 05:00 PM, Andy Green wrote:
>>> On 12 February 2017 05:23:20 GMT+08:00, Per Bothner <per at bothner.com>
>>> wrote:
>>>> I'm using libwebsockets for my JavaScript-based DomTerm terminal
>>>> emulator
>>>> (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.
>> Thanks - I'm pretty excited about it.
>> I previously uses Java-WebSocket (or for qtdomterm I used Qt's internal
>> WebSocket server). However, I'm happy to deprecate Java-WebSocket in
>> favor of libwebsockets, for multiple reasons: The latter would typically
>> use less resources; it is nice to have http and ws on the same port;
>> and Java-WebSocket is not seeing any development.
>> I'd like to give some credit to Shuanglei Tao, whose ttyd made it
>> a lot easier to switch to libwebsockets.  ldomterm is basically ttyd
>> but with xterm.js replaced by DomTerm.  (Plus I added options to
>> automatically open a browser window.)
>>> 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
>>> https://github.com/warmcat/libwebsockets/blob/master/lib/libwebsockets.h#L4177
>>> 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.
>> Thanks - I will look into serving from a zip archive - but initially
>> without
>> attempting to serve compressed data.  The latter will be a nice
>> optimization
>> that can be added when lws has the necessary support.
> The suggested changes are added on master now.
> I wasn't completely sure about the relationship between gzip and deflate
> tokens in the headers.  What I did is added both "gzip" and "deflate"
> need to be coming in to understand we could send gzip format, and if the
> .open() handler chose to do it, we will send "gzip, deflate" as the
> Content-Encoding.  If when you get to the point of testing it that's not
> right, we can change it.
> -Andy
> -Andy
>> I expect I'll have more questions soon.
> _______________________________________________
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
> https://libwebsockets.org/mailman/listinfo/libwebsockets

More information about the Libwebsockets mailing list