andy at warmcat.com
Thu Jun 11 10:13:15 CEST 2020
On 6/11/20 8:40 AM, mbargauan at comm5g.com wrote:
> I had the fancy idea of using lws_callback_http_dummy and found:
> * Nothing in documentation - item is bold with no link
It's a default handler of interest if you want to inherit http-related
stuff like proxying and cgi. Just have your callback call through to it
for stuff you didn't handle yourself, as is done in many of the minimal
If you don't provide any protocols at all, it takes up the whole task of
"being the protocol" callback by default. You don't even reference it
in user code in that case.
Otherwise, it's not just undocumented, it's "undocumented" ie, what's in
there is in there to satisfy lws internals. There is no promise at all
about that staying the same. It should act well if you call through to
it for stuff you don't know about or handle is all.
> * Unexpected errors in browsers due to page policy violation
> * No messages in last 2 years on this topic
... and so what, it means it has been working well for two years since
nobody complains about it...
> * ....
> What is the future of this function?
> Errors come from HTTP header with very restrictive policy, but with
> simple analisis - more required.
> Any doc or other source on that?
> Make sense to complete doc and work on this function or drop and forget
> as soon-obsolete?
No. It's the backbone of default http related activity in lws, it is
not going anywhere. You have the sources, you can just look at it and
divine that, or grep for what is using it.
The minimal examples all use the super restrictive CSP and have no
errors in recent Firefox and Chrome. All of libwebsockets.org and
warmcat.com use the same restrictive CSP with pinholes for shields.io
and the like.
> Thank you
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
More information about the Libwebsockets