[Libwebsockets] serving compressed http response from a zip archive

Andy Green andy at warmcat.com
Wed Mar 1 06:38:27 CET 2017

On March 1, 2017 2:00:27 PM GMT+09:00, Per Bothner <per at bothner.com> wrote:
>On 02/28/2017 05:04 PM, Andy Green wrote:
>> The new fops stuff holds the active fops in the "fop_fd" after
>.open()... the idea is you can either select the fops before open(), or
>in your fops[0].open() treat the fops as the start of an array of fops
>structs with a NULL .open sentinel at the end, and choose the right
>operations, calling through to his .open and he will store his fops
>pointer into the fop_fd, so it will be his read(), close() etc that is
>called on that fd subsequently.
>> To help that I pushed a patch adding a const char *path_prefix;
>member in the fops... you can set this to the left part of the
>filesystem namespace that fops is to be used with.
>I'm a bit confused by that.  Who sets path_prefix? Presumably, it
>should be
>done based on the selected mount - but how should that be done?

No path_prefix belongs to the fops struct not the mount.

The layers are

 - url namespace
  (... mount... )
 - vfs path
  (... fops ...)
 - fops-specific subpath

The mount maps the URL namespace to the vfs namespace.

If we have the mount with url mountpoint "/docs" and the file:// origin "/var/www/zipped/docs", if the url comes "/docs/index.html" then the translation job of the mount ends at converting that to "/var/www/zipped/docs/index.html".

The fileserving part requests "/var/www/zipped/docs/index.html" from the vfs... then "something" will try to find the right fops, by checking for best match of each fops .path_prefix.  (I just realized this is not quite possible yet... I'll send a patch allowing this in a few minutes)

If your "gzip-aware" fops has its .path_prefix set to "/var/www/zipped", it will get selected by the example above and should deliver whatever "./docs/index.html" means to him.

>> So, eg, if your mount says URL namespace "/user-manual" has a
>filesystem origin of "/zipped/user-manual", your fops[0].open can match
>it on, say, fops[2].path_prefix, which is "/zipped".  fops[2]
>open/read/close are then used for that fop_fd.
>> Possibly some of this is better done in lws rather than your
>fops.open()... feel free to suggest it if it starts to feel like that.
>To be clear: I'm fine the way it is currently working.
>You expressed interest in having this feature (serving resources
>from a zip archibe, and sending compressed data in the http response
>the data comes from zip archive) be part of the standard libwebsockets
>distribution.  So the whole point is that it be "done in lws".

Yes.  But I meant from a generic library perspective the code walking the fops array should maybe be some official api exposed by lws for other cases / mixes of fops.  I think I should do that now as well.


More information about the Libwebsockets mailing list