[Libwebsockets] lws_callback_http_dummy

[Andy Green]

On 6/11/20 10:14 AM, mbargauan at comm5g.com wrote:
> Thank you Andy.
> 
> Let me add some details on what I found :
> 
>   * Error - I have my Index.html and example.js as attached

Nothing was attached.  But honestly, I don't really want to look at your 
index.html or example.js.  It's not interesting to me if you have some 
broken things - I have to reason to care, right? - but it's interesting 
to both of us if I have some broken things.

As I said the minimal examples use strict CSP, if it's broken, you 
should be able to show it broken using the minimal examples unchanged, 
or libwebsockets.org or warmcat.com.  Then, if I can reproduce it, I can 
do something about it.

If it's just your stuff that's broken, that's nothing to do with me.

>   * Firefox has this message "Content Security Policy: The page’s
>     settings blocked the loading of a resource at inline (“script-src”)."
>   * Similar on Chrome

Eg, your fetch address must match that in the CSP, or CSP will do its 
job on it.  That's nothing to do with lws.

>   * Attached wireshark files - err1 is what is delivered with
>     lws_callback_http_dummy, err2 what is delivered by test-server.c
>     server program with coded HTTP server. HTTP header is the difference.
> 
> Ok, lws_callback_http_dummy is here and will stay forever.
> But it would be nice if in the documentation there is some details for 
> newcomers, just to avoid spending some days as I did to point out actual 
> behaviour.

I really don't think lws got in your way for 'days'.

> I am been successfully working with libwebsockets since 2.3 and now 
> moving to 4.0 on Arm and X64 platforms, but not always with optimum 
> efficiency due to criptical documentation. Suggestion: what about adding 
> some search feature to Documentation and Mailinglist ?

I have a long-term plan for this using full-text search in gitohashi, 
contributions welcome

https://warmcat.com/git/gitohashi

The FTS trie extraction, partial search matching and caching already 
works but it needs debugging and UI integration.

-Andy

> Thank you
> Mike
> From"Andy Green" andy at warmcat.com
> Tombargauan at comm5g.com, libwebsockets at ml.libwebsockets.org
> Cc
> DateThu, 11 Jun 2020 09:13:15 +0100
> SubjectRe: [Libwebsockets] lws_callback_http_dummy
> 
> 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:
> ... okay...
>>   * 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
> examples.
> 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
> ... details?
>>   * 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.
> -Andy
>> Thank you
>> Mike
>> 
>> _______________________________________________
>> Libwebsockets mailing list
>> Libwebsockets at ml.libwebsockets.org
>> https://libwebsockets.org/mailman/listinfo/libwebsockets
>>