5👍
Yes, thanks to uwsgi_param or proxy_set_header HTTP_X_Forwarded_Proto header is set (otherwise it won’t be present) and django app (working via http behind https proxy) can know, that original request was secure (via https).
Nginx forwards initial http request to underlying upstream server.
For this it may use different protocols – uwsgi if uwsgi_pass directive is set or http if proxy_pass directive is set. Only one of them needs to be set in block.
By default nginx forwards all original request headers to upstream, which is controlled by proxy_pass_request_headers and uwsgi_pass_request_headers options. With proxy_set_header or uwsgi_param headers and their values can be set / added explicitly.
With proxy_pass – request is forwarded as HTTP request to upstream server. And with proxy_set_header headers and their value to be passed can be set.
With uwsgi_pass request is forwarded via uwsgi binary protocol. It is not http, it has no ‘headers’, instead it has parameters to be passed by uwsgi_param (if parameter name is prefixed with HTTP_ – it is available as a header in wsgi app).
Uwsgi is native for wsgi servers (but most can work via http as well) and allows more fine-tuning of how request can be processed by wsgi server with parameters passed. And with configuration can be more performant. However the difference may be very subtle.
Several cases when http is desired (and main reason is its universality):
- for internal communication between services directly
- you may want to use or try other https proxy other than nginx (and today there are many) and it may not support uwsgi
- with microservice approach – there may be other proxies / sidecars between nginx and uwsgi (for authentication, logging, etc) and they will work only with http