[Libwebsockets] serving compressed http response from a zip archive
denis.osvald at sartura.hr
Mon Feb 13 11:31:37 CET 2017
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
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.
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>
>>>> (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
>>> 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
>> attempting to serve compressed data. The latter will be a nice
>> 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.
>> I expect I'll have more questions soon.
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
More information about the Libwebsockets