[Libwebsockets] re-directing 404 to a default webpage when using lwsws with standalone plugins
andy at warmcat.com
Wed Mar 7 13:19:52 CET 2018
On 03/07/2018 05:37 PM, Andy Green wrote:
> On 03/07/2018 05:27 PM, Andrew Carney wrote:
>> We are running libwebsockets 2.2.1 and building with buildroot, and
>> using lwsws with stand alone plugins.
>> We currently have lwsws running with several plugins which are written
>> in C++ and compiled under linux using g++
>> One of our plugins is simply passing data and URLs between a user
>> interface ( a qt webkit browser ) and a java application.
>> The java application can send URL to the plugin, which then results in
>> the browser loading said URL.
>> Sometimes, things don't always work as expected, and we end up getting
>> a 404 , page not found.
>> What I would like to be able to do is make lwsws always load a default
>> page, which is available on a mountpoint instead of returning a 404
>> I have looked into this, but can see no obvious or simple way to do this.
>> I am obviously missing something here, but any hints would be greatly
> At the moment it's just hardwired to a canned set of 404 headers.
> I think it's a good idea, I'll take a look later at maybe adding the
> possibility to give a URL path in the vhost that it will try one time to
> use instead to render the 404, if that isn't defined or fails it can
> just fall back to what it does today.
This exists on master now, currently
vhost: add 404 handler url option
This allows you to set a 404 handler URL on a vhost.
The necessary user code looks like...
info.error_document_404 = "/404.html";
... at vhost-creation time.
In the existing lws_return_http_status() api, if it sees
the vhost has an "error_document_404" path set and that
we are trying to report a 404, it changes the action
instead to a redirect to the error_document_404 path.
The redirect target is returned using 404 status code.
If the redirect target doesn't exist, then it falls back
to just reporting the simple canned 404.
>> All our plugins work perfectly, and as expected apart from this little
>> "nice to have"
>> Libwebsockets mailing list
>> Libwebsockets at ml.libwebsockets.org
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
More information about the Libwebsockets