uwsgi_param 和 proxy_set_header 之间的区别

Question

在 uWSGI/Django 中使用 Nginx 作为反向代理时，Nginx 配置中的 uwsgi_param and proxy_set_header 有什么区别？ uWSGI 参数是像 HTTP header，还是完全不同，如果是，它的目的是什么？

背景：我正在 Django 中对 security-related HTTP headers 进行一些修补。我有一个使用 Nginx 作为反向代理的设置，uWSGI 服务于 Django 应用程序并作为代理服务器：

                           _____________________________________
                           |                                    |
            http or https* |           uwsgi                    |
   browser --------------> | nginx --------------> uWSGI/Django |
                           |____________________________________|

* http 301-redirects to https equivalent;
  https response returns Strict-Transport-Security header

这里http请求'become' https请求有两种机制：

Nginx 将端口 80 请求重定向到 443，例如请求历史链有一个 301 重定向
HTTP 响应包含 Strict-Transport-Security: max-age=31536000; includeSubDomains; preload 响应 header；在这种情况下，永远不会有 302 重定向；浏览器接受客户端 http 请求并立即将其强制为等效的 https。

也就是说，相关的 Django 设置如下所示：

# tail -n4 project/settings.py
SECURE_HSTS_SECONDS = 31536000  # Seconds; *USE A SMALLER VALUE FOR TESTING FIRST!*
SECURE_HSTS_PRELOAD = True
SECURE_HSTS_INCLUDE_SUBDOMAINS = True
SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")

和 Nginx 配置：

server {
    server_name .mydomain.com;
    listen 80;
    return 301 https://$host$request_uri;
}

server {
    location / {
        uwsgi_pass localhost:8000;
        include uwsgi_params;
        uwsgi_param X-Forwarded-Proto "https";
        proxy_set_header X-Forwarded-Proto "https";
    }
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/mydomain.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/mydomain.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

那么，当 Django 应用程序得知原始连接是通过 SECURE_PROXY_SSL_HEADER 的 HTTP 时，它是否要感谢 uwsgi_param 或 proxy_set_header？ proxy_set_header 是否仍然实际使用，因为协议是 uwsgi 而不是 proxy_pass: http://localhost:8000？ uwsgi_param 有什么作用？我在协议描述中看到 very little。它的行为类似于 HTTP header，还是完全不同？

Answer 1

是的，感谢uwsgi_param或proxy_set_header HTTP_X_Forwarded_Proto header设置（否则不会出现) 和 django 应用程序（通过 https 代理后面的 http 工作）可以知道，原始请求是安全的（通过 https）。

Nginx 将初始 http 请求转发到底层上游服务器。为此，它可能使用不同的协议 - uwsgi 如果设置了 uwsgi_pass 指令，或者 http 如果设置了 proxy_pass 指令。 只有其中一个需要在block中设置

nginx 默认将所有原始请求 header 转发到上游，由 proxy_pass_request_headers 和 uwsgi_pass_request_headers 选项控制。使用 proxy_set_header 或 uwsgi_param header 可以显式设置/添加它们的值。

使用 proxy_pass - 请求作为 HTTP 请求转发到上游服务器。并且可以设置proxy_set_header headers 和它们要传递的值。

With uwsgi_pass 请求通过 uwsgi 二进制协议转发。它不是 http，它没有 'headers'，而是具有要由 uwsgi_param 传递的参数（如果参数名称以 HTTP_ 为前缀 - 它可以作为 header在 wsgi 应用程序中）。

Uwsgi 是 wsgi 服务器的本机（但大多数也可以通过 http 工作）并且允许更多 fine-tuning wsgi 服务器如何处理请求并传递参数。并且配合配置可以提高性能。然而，差异可能非常细微。

需要http的几种情况（主要原因是它的普遍性）：

直接用于服务之间的内部通信
您可能想使用或尝试除 nginx 以外的其他 https 代理（现在有很多）并且它可能不支持 uwsgi
使用微服务方法——nginx 和 uwsgi 之间可能有其他代理/sidecar（用于身份验证、日志记录等），它们只能与 http

uwsgi_param 和 proxy_set_header 之间的区别

Difference between uwsgi_param and proxy_set_header

python

django

nginx

uwsgi