[Libwebsockets] serving compressed http response from a zip archive
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
>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
>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 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.
>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)+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