httpd: `fastcgi param` is broken

Hi,

Is it intended behavior, that `fastcgi param`
doesn't overwrite variables?

I have the following httpd config:

server "example" {
listen on * port 80

location "/test/" {
root "/cgi-bin/env.cgi"
fastcgi param SERVER_NAME "env"
fastcgi
}
}


env.cgi is just this C program, statically linked:

#include <stdio.h>

int main (void)
{
extern char **environ;

printf ("Content-Type: text/plain\r\n\r\n");

for (char **e = environ; *e != NULL; ++e) {
puts (*e);
}

return 0;
}

When I open in a web browser, I get this:
SERVER_SOFTWARE=OpenBSD httpd
SERVER_PROTOCOL=HTTP/1.1
SERVER_NAME=example # this doesn't get overwritten
SERVER_PORT=80
SERVER_ADDR=127.0.0.1
REQUEST_URI=/test/
REQUEST_METHOD=GET
REMOTE_PORT=40767
REMOTE_ADDR=127.0.0.1
SERVER_NAME=env # note these duplicates
SERVER_NAME=env
HTTP_USER_AGENT=Mozilla/5.0 (X11; Linux x86_64; rv:132.0) Gecko/20100101
Firefox/132.0
HTTP_UPGRADE_INSECURE_REQUESTS=1
HTTP_SEC_GPC=1
HTTP_SEC_FETCH_SITE=cross-site
HTTP_SEC_FETCH_MODE=navigate
HTTP_SEC_FETCH_DEST=document
HTTP_PRIORITY=u=0, i
HTTP_HOST=example
HTTP_DNT=1
HTTP_CONNECTION=keep-alive
HTTP_ACCEPT_LANGUAGE=en-US,en;q=0.5
HTTP_ACCEPT_ENCODING=gzip, deflate, br, zstd
HTTP_ACCEPT=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
GATEWAY_INTERFACE=CGI/1.1
DOCUMENT_URI=/test/
DOCUMENT_ROOT=/cgi-bin/env.cgi
QUERY_STRING=
SCRIPT_FILENAME=/cgi-bin/env.cgi
SCRIPT_NAME=
PATH_INFO=/test/


The actual use-case involves Gotwebd,
which removed removed the ability
to specify per-server `listen on socket`.

Re: NIC

> list the chipsets it supports

You may find it later that "supported" is not what you are thinking of.
There is something there as a hardware driver, but sometimes is an
ugly puzzle gathered from multiple sources, most of the time without
vendor documentation, not tested enough, etc. Some developers my get
angry with my remarks, but maybe I should let them evaluate the
drivers.

Anyway, depending of hardware, be prepared to find out that some
options are not available, some are badly working and some are fine
for the daily usage because some users tested them in production and
had no major issues or no issues at all.

No offense intended to anyone. It is what it is, the drivers are not
pure algorithms waiting for someone to code the, they usually rely
heavily on vendor documentations.

If more people ask for it, I can try to write a poem about network,
even with my bad english.