Comment 6 for bug 1744739

It shouldn't be that you have to provide a "new" param because all we're doing is passing the ones in the whitelist if they are provided. If a param is not provided it can't be passed, but 2.1.24 works without it so 2.1.25 should too.

As far as ones we don't pass that are provided, I'm guessing CONTENT_LENGTH might be the issue, but I'm having trouble understanding why.

I'm having difficulty because I'm missing a piece here. I.e. uwsgi presumably expects to invoke a wsgi application, but the normal flow in Mailman is the web server invokes a CGI wrapper (say private) which is one of the things compiled using the code in src/common.c and which lives in Mailman at $prefix/cgi-bin/private. That wrapper is SETGID to Mailman's group. It does some checks, trims the environment and invokes $prefix/scripts/driver which understands which CGI is requested and invokes (in this example) Mailman/Cgi/private.py.

None of this is a wsgi application.

So what is the flow in your case?

One basic question is how do you install Mailman. If you build it from source, you could just edit src/common.c to add CONTENT_LENGTH=, DOCUMENT_ROOT=, SERVER_PROTOCOL=, REQUEST_SCHEME=, HTTPS= and REMOTE_PORT= to the keepenvars list and see if that lets it work.

Also, I have a somewhat uneasy feeling about this because even though I said I thought this was the likely cause, if it is I would expect it to affect all the CGIs. Does listinfo work? If so, then this trimming of the environment may not be the issue after all.

If listinfo works, then you might try in your 2.1.24 installation, replacing the two occurrences of cgidata.getvalue with cgidata.getfirst in Mailman/Cgi/private.py and see if that breaks it.