python - uwsgi_param 和 proxy_set_header 的区别

Question

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

---

背景:我正在对 Django 中与安全相关的 HTTP header 进行一些修补。我有一个使用 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请求在这里“变成”https请求有两种机制:

1. Nginx 将端口 80 请求重定向到 443，例如请求历史链有一个 301 重定向
2. HTTP 响应包含 Strict-Transport-Security:max-age=31536000；包括子域；预加载 响应头；在这种情况下，永远不会有 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 的 HTTPs 时，它是否有 uwsgi_param 或 proxy_set_header 要感谢？ proxy_set_header 是否仍然实际使用，因为协议(protocol)是 uwsgi 而不是 proxy_pass: http://localhost:8000？ uwsgi_param 有什么作用？我看到 very little在协议(protocol)描述中。它的行为类似于 HTTP header ，还是完全不同？

Answer 1

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

---

Nginx 将初始 http 请求转发到底层上游服务器。为此，它可能使用不同的协议(protocol) - 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 header 及其要传递的值。

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

Uwsgi 是 wsgi 服务器的 native (但大多数也可以通过 http 工作)并且允许对 wsgi 服务器如何通过传递的参数处理请求进行更多微调。并且配合配置可以提高性能。然而，差异可能非常细微。

需要http的几种情况(主要原因是它的普遍性):

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