[Libwebsockets] problems with big dynamic content

Andy Green andy at warmcat.com
Sat Jun 23 09:48:03 CEST 2018



On 06/23/2018 12:07 PM, Per Bothner wrote:
> On 06/22/2018 03:48 PM, Andy Green wrote:
> 
>> Just set it to something large, like 5 * 365 * 3600 (5 years)?
> 
> Thanks.  I checked in this patch:
> 
> diff --git a/lws-term/server.c b/lws-term/server.c
> index 84e2ee3..ff814ec 100644
> --- a/lws-term/server.c
> +++ b/lws-term/server.c
> @@ -931,6 +931,10 @@ int
>   main(int argc, char **argv)
>   {
>       memset(&info, 0, sizeof(info));
> +#if LWS_LIBRARY_VERSION_NUMBER <= 2004002
> +    // See "problems with big dynamic content" thread on libwebsockets 
> list
> +    info.keepalive_timeout = 0x7fffffff;
> +#endif
>       info.port = 0;
>       info.iface = NULL;
>       info.protocols = protocols;

I pushed an additional patch on v3.0-stable and master... on v3.0-stable 
it adds a private api lws_open(), which is a wrapper for open + setting 
CLOEXEC if the platform has it, and converts the internal library file 
opens to use it.  The parent cgi pipe sides also get CLOEXEC after their 
vfork, so user forks can't pick them up if it happens while they're up.

On master it does those things and also exposes the lws_open() api 
publicly, and converts plugin and test app file opens to use it.

Only unix plat understands CLOEXEC, windows doesn't even have fork(), 
ESP32 and OP-TEE don't have processes even.

I confirmed the cgi stuff is still happy on libwebsockets.org.

-Andy



More information about the Libwebsockets mailing list