[Libwebsockets] serving compressed http response from a zip archive

Andy Green andy at warmcat.com
Mon Feb 13 18:53:57 CET 2017

On February 14, 2017 1:41:59 AM GMT+08:00, Per Bothner <per at bothner.com> wrote:
>On 02/11/2017 05:00 PM, Andy Green wrote:
>> 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
>Is there any particular advantage to using the VFS hook, rather than
>just calling lws_write etc?

Yeah... mounts do a lot more http business than just call lws_write, eg etag and cache management, if-modified-since handling etc.

You'll be able to benefit from that by putting it at vfs layer.

>I cobbled together a VFS solution, though it's not quite working, due
>(I think)
>to the error handling.  (I'm getting a timeout when a missing
>favicon.ico is requested.)
>I think it will be easier and cleaner to just modify the existing
>lws_write support
>used for "compiled-in" resources.

That's certainly not so from perspective of lwsws and the 'proper' support in the file serving path.

>The VFS layer isn't really usable as a general VFS layer.  The problem
>is lws_filefd_type
>is platform-specific and not extendable.  I couldn't find any clean way

I have used it to serve files from a romfs on esp8266.  But it's true I did that by making esp8266 an lws platform, with a void * file fd.

>to distinguish
>the zip-based files from native files.

One way to do that is partition the url namespace.

>I implemented a Unix-only kludge where file id's above 1000 are mapped
>to a table:
>#define MAX_OPEN_MEM_FILES 32
>struct open_mem_file open_mem_files[MAX_OPEN_MEM_FILES];
>#define lws_filefd_to_mem_file(FD) \
>   ((FD) >= 1000 ? &open_mem_files[(FD)-1000] : NULL)
>#define mem_file_to_lws_filefd(MEM) (((MEM)-&open_mem_files[0])+1000)
>This is pretty ugly, and only works when lws_filefd_type is an int.

How about modify the vfs to take a struct with the existing platform fd type, and a private void * just for use of the vfs part?  Is it enough?

>(I haven't looked yet at the optimization of shipped compressed data.
>The decompress-on-the-server mode is needed regardless.)

Yes.  But the interface for that's already solved on lws side.


More information about the Libwebsockets mailing list