Comment 5 for bug 1744739

That sounds plausible.

I can show you what nginx does in my case (the relevant part):

``
# Send all access to / to uwsgi
location / {
  gzip off;
  include uwsgi_params;
  uwsgi_modifier1 9;
  uwsgi_pass unix:/run/uwsgi/mailman.sock;
}
``

where uwsgi_params consists of the standard, shipped params:

``
uwsgi_param QUERY_STRING $query_string;
uwsgi_param REQUEST_METHOD $request_method;
uwsgi_param CONTENT_TYPE $content_type;
uwsgi_param CONTENT_LENGTH $content_length;

uwsgi_param REQUEST_URI $request_uri;
uwsgi_param PATH_INFO $document_uri;
uwsgi_param DOCUMENT_ROOT $document_root;
uwsgi_param SERVER_PROTOCOL $server_protocol;
uwsgi_param REQUEST_SCHEME $scheme;
uwsgi_param HTTPS $https if_not_empty;

uwsgi_param REMOTE_ADDR $remote_addr;
uwsgi_param REMOTE_PORT $remote_port;
uwsgi_param SERVER_PORT $server_port;
uwsgi_param SERVER_NAME $server_name;
``

To sum it up:

What's not available in the nginx params but in the allowed mailman params: HOST, HTTP_COOKIE, HTTP_FORWARDED_FOR, HTTP_HOST, HTTP_X_FORWARDED_FOR, LOGNAME, SCRIPT_NAME, USER

What's not available in the allowed mailman params, but in the nginx params: CONTENT_LENGTH, DOCUMENT_ROOT, SERVER_PROTOCOL, REQUEST_SCHEME, HTTPS, REMOTE_PORT

I guess one of the params from the second list is needed to keep nginx happy? Or is it the other way round and I now need to provide a param, that I haven't before?