[Libwebsockets] serving compressed http response from a zip archive

Andy Green andy at warmcat.com
Sun Feb 12 11:54:08 CET 2017



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.




More information about the Libwebsockets mailing list