Missing gunicorn features

[multimeric]

I have been stuck for a very long time deploying my web app because of some of the gunicorn features that get disabled when using the meinheld worker with gunicorn. To be clear, I've been using the https://hub.docker.com/r/tiangolo/meinheld-gunicorn/dockerfile Docker images, which run gunicorn -k egg:meinheld#gunicorn_worker (I believe this is the normal way to use the meinheld runner).

Some of the features I have encountered that are listed in the gunicorn docs that don't work with a meinheld worker:

• The "secure scheme" feature, which sets wsgi.url_scheme = "https" when certain headers (such as X-Forwarded-Proto) are provided, which is quite crucial when using gunicorn behind a proxy. Using meinheld, this feature doesn't seem to work, so that no matter how the request is made, the url_scheme is never changed, meaning that all the redirects served by my app are to http:// URLs instead of https://. As soon as I revert to the default gunicorn worker, all my URLs are fixed
• Worker hooks, namely pre_request and post_request, which are functions provided in the config that are supposed to be run at the appropriate stage of the server workflow, do not seem to be run at all
• The meinheld worker does not seem to respect the access_log_format, it instead always returns the same log format. For example if I set access_log_format = '%(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s" %({x-forwarded-proto}i)s %({location}o)s', which is a valid format string using valid headers, the meinheld worker will always return 127.0.0.1 - - [06/Jan/2021:06:55:32 +0000] "GET /logout HTTP/1.0" 308 265 "-" "curl/7.58.0" - - , while the sync worker will correctly fill in the header values: 127.0.0.1 - - [06/Jan/2021:06:52:13 +0000] "GET /logout HTTP/1.0" 308 267 "-" "curl/7.58.0" https https://localhost:8000/logout/
• The worker seems to ignore SIGTERM, since Ctrl+C does not shut down gunicorn + meinheld, but does shut down gunicorn + sync

I suspect there are more of these, but I think it's important that these are at least documented here as an issue, ideally documented on the meinheld website, and possibly even fixed at some point. I recognise that many of these features are gunicorn gravy that aren't essential when running a production web app, so perhaps fixing these isn't so urgent.

[dwreeves]

I ran into the first issue as well. Wrapping my WSGI app with werkzeug.middleware.proxy_fix.ProxyFix did the trick.

I actually had no idea this was a Meinheld issue. But, I just checked by rerunning my integration server without Meinheld workers and without ProxyFix-- and sure enough, the issue I initially had with redirects bouncing to http went away.