uwsgi_param和proxy_set_header之间的区别 [英] Difference between uwsgi_param and proxy_set_header

问题描述

将Nginx用作uWSGI / Django的反向代理时， uwsgi_param 和 proxy_set_header 在Nginx配置中？ uWSGI参数是像HTTP标头一样，还是完全不同，如果是，它的目的是什么？

When using Nginx as a reverse proxy with uWSGI/Django, what is the difference between uwsgi_param and proxy_set_header in an Nginx configuration? Is a uWSGI parameter like an HTTP header, or is it completely different, and if so, what is its purpose?

背景：我正在对Django中与安全相关的HTTP标头进行一些修改。我有一个使用Nginx作为反向代理的设置，其中uWSGI服务Django应用并作为代理服务器：

Background: I'm doing some tinkering around with security-related HTTP headers in Django. I have a setup using Nginx as reverse proxy, with the uWSGI serving the Django app and being the proxied server:

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

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

http请求有两种机制在此处成为 https请求：

There are two mechanisms by which http requests 'become' https requests here:

1. Nginx将端口80请求重定向到443，例如请求历史记录链具有301重定向


2. HTTPs响应包含 Strict-Transport-Security：max-age = 31536000; includeSubDomains; preload 响应头；在这种情况下，永远不会有302重定向；

1. Nginx redirects port 80 requests to 443, e.g. the request history chain has a 301 redirect
2. HTTPs responses contain a Strict-Transport-Security: max-age=31536000; includeSubDomains; preload response header; in this case, there is never a 302 redirect; the browser takes the client http request and forces it to its https equivalent right off the bat.

这就是所有相关的内容。 Django设置如下：

All that is to say, the related Django settings look like:

# 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 的作用是什么？我看到非常小。

So, when the Django app gets word that the original connection was HTTPs via SECURE_PROXY_SSL_HEADER, does it have uwsgi_param or proxy_set_header to thank? Is proxy_set_header still actually used because the protocol is uwsgi rather than proxy_pass: http://localhost:8000? What does a uwsgi_param do? I see very little in the protocol description. Does it behave like an HTTP header, or is it totally different?

推荐答案

是的，要感谢 uwsgi_param 或 proxy_set_header HTTP_X_Forwarded_Proto 标头已设置（否则会赢'不存在）和django应用程序（通过https代理后面的http工作）可以知道，原始请求是安全的（通过https）。

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将初始http请求转发到基础上游服务器。
为此，它可以使用不同的协议-如果设置了 uwsgi_pass 指令，则使用 uwsgi ；如果设置了<$，则使用 http 设置了c $ c> proxy_pass 指令。 仅其中一个需要在块中设置。

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.

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

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.

使用 proxy_pass -请求作为HTTP请求转发到上游服务器。并使用 proxy_set_header 标头及其要传递的值可以设置。

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.

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

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是wsgi服务器的本机（但大多数也可以通过http来工作）并且允许wsgi服务器如何通过传递的参数对请求进行更精细的调整。并且借助配置可以提高性能。但是，差异可能非常微妙。

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.

在需要http的情况下（主要是通用性）：

Several cases when http is desired (and main reason is its universality):

• 直接在服务之间进行内部通信


• 您可能想使用或尝试使用除nginx以外的其他https代理（今天有很多），并且不支持使用微服务方法的uwsgi


• -nginx和uwsgi之间可能还有其他代理/小工具（用于身份验证，日志记录等），它们仅适用于http

这篇关于uwsgi_param和proxy_set_header之间的区别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！