Re: httpd: don't send the fastcgi param struct over imsg and tweaks

On Sat, 18 Jul 2026 08:58:49 +0200,
Rafael Sadowski <[email protected]> wrote:
> 
> Yes and No. That's a very good point if you look at the diff in
> isolation, but we've already sorted that out with the [1] diff:
> 
> +	if ((srv->srv_conf.flags & SRVFLAG_LOCATION) == 0) {
> +		/* Configure TLS if necessary. */
> +		if (config_setserver_tls(env, srv) != 0)
> +			return (-1);
> +	}
> +
> +	/* Configure FCGI parameters if necessary. */
> +	if (config_setserver_fcgiparams(env, srv) != 0)
> +		return (-1);
> +
> 
> You've given your OK for this. Here, we check the return value and exit
> with -1 if a proc_composev fails. Sure we could quit with fail()
> directly but I think it's better to push the error up the chain. In the
> end with end up with a fail().
> 
> 1: https://marc.info/?l=openbsd-tech&m=178429421655440&w=2
>

Toooo many patches in parallel for the same code, and yes, I read each in
separate like it will be applied without everything else.

Anyway, here the one small nith.

> @@ -65,8 +65,8 @@
>  #define HTTPD_TLS_CIPHERS	"secure"
>  #define HTTPD_TLS_DHE_PARAMS	"none"
>  #define HTTPD_TLS_ECDHE_CURVES	"default"
> -#define HTTPD_FCGI_NAME_MAX	511
> -#define HTTPD_FCGI_VAL_MAX	511
> +#define HTTPD_FCGI_NAME_MAX	512
> +#define HTTPD_FCGI_VAL_MAX	8192

Inside yylex() it uses buf[8096], what makes that HTTPD_FCGI_VAL_MAX wired.

I think we should move 8096 to named constatnt and bump it up.

OK kirill@ with move that constant to named one, and bump it to 16384 which
reads safe.

-- 
wbr, Kirill