[Libwebsockets] serving compressed http response from a zip archive
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.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
>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.open can match
>it on, say, fops.path_prefix, which is "/zipped". fops
>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