缺少 django、nginx 和 Gunicorn 的自定义标头

Question

免责声明：

我正在一个项目中工作，其中存在一个“巨大”的 Web 应用程序，该应用程序具有适用于手机的 api，因此更改 api 不是一个选项。

这个应用程序是很久以前开发的，有几个开发人员已经开发过它，

话虽如此，问题是这样的；

在此站点的移动 api 中（仅查看而不是返回 json 数据），代码正在查找令牌，但在请求标头中查找令牌：

token = request.META.get('HTTP_TOKEN')

当我在本地测试此 api 时，工作正常，但在生产中则不然，所以，我试图弄清楚发生了什么，发现了这个：

django 将标头，甚至自定义标头转换为 request.META 中的键，我使用 urllib2 和 测试 api 的请求，生产中的问题是在生产服务器中 request.META 永远不会有一个名为 HTTP_TOKEN 的密钥，因此，做了一些调试，我认真地认为问题出在我们服务 django 应用程序的方式上。

我们使用django1.3、nginx、gunicorn、virtualenvwrapper、python2.7。

我的主要嫌疑人是nginx，我认为，nginx以某种方式接收标头，但不将其转发给django，我尝试对此进行一些研究，但我只找到了有关来自nginx的安全标头和自定义标头的信息，但我没有找到doc 或有关如何告诉 nginx 允许该标头并且不删除它的内容。

我在这里需要帮助，第一件事是测试 nginx 是否收到标头，但我对 nginx 只了解一点，我不知道如何告诉它记录请求的标头。

谢谢

更新

nginxconf 文件

Answer 1

如果使用 uwsgi_pass 访问 Django，则在适当的位置 ...

# All request headers should be passed on by default     
# Make sure "Token" response header is passed to user 
uwsgi_pass_header  Token;

如果使用 fastcgi_pass 访问 Django，则在适当的位置 ...

# All request headers should be passed on by default     
# Make sure "Token" response header is passed to user 
fastcgi_pass_header  Token;

如果使用 proxy_pass 访问 Django，则在适当的位置）...

# All request headers should be passed on by default
# but we can make sure "Token" request header is passed to Django 
proxy_set_header Token $http_token;

# Make sure "Token" response header is passed to user 
proxy_pass_header  Token;

这些应该有助于消除 Nginx 没有从您的问题中传递信息的可能性。

Answer 2

在 nginx 配置文件 (fe mysite_nginx.conf) 的 server 部分中添加以下参数：uwsgi_pass_request_headers on;。

例如：

server {
    # the port your site will be served on
    listen      8000;

    ...

    underscores_in_headers on;
}

如果通过uwsgi_pass访问Django，则需要在location部分添加uwsgi_pass_request_headers on;这一参数。

例如：

location / {
    include     /etc/nginx/uwsgi_params; # the uwsgi_params file you installed
    uwsgi_pass_request_headers on;
    uwsgi_pass  django;
}

Answer 3

我认为这就是您所需要的：

log_format combined '$remote_addr - $remote_user [$time_local]  '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent" "$http_http_token" "$upstream_http_http_token"'

记录正在发生的事情。

您可以更深入地查看上游代理模块上的 proxy_set_header 部分，以了解如何传递所需的标头。

您可以在此处找到文档：

• http://wiki.nginx.org/HttpLogModule
• http://wiki.nginx.org/NginxHttpUpstreamModule
• http://wiki.nginx.org/NginxHttpProxyModule#proxy_set_header
• http://wiki.nginx.org/HttpProxyModule#proxy_pass_request_headers

最后一项似乎表明 nginx 默认传递大多数标头

Answer 4

我没有找到真正的答案，但能够找到解决方法。我在使用 RFC 标准标头 if-none-match 和 if-modified-since 时遇到了同样的问题，因此我的解决方案针对这些标头进行了测试。

添加到我的 nginx 配置中：

uwsgi_param HTTP_IF_NONE_MATCH $http_if_none_match;
uwsgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since;

我无法解释为什么 nginx 默认拒绝将这些标头传递给 uwsgi。这个配置强制它。页面现在会根据情况生成 304。

对于有关非标准“令牌”标头的原始问题，这应该可以解决问题：

uwsgi_param HTTP_TOKEN $http_token;

Answer 5

上面的答案足以让我们找到出路。但还有一个令人烦恼的问题我们需要知道。是的，这很烦人。

proxy_set_header X_FORWARDED_FOR # oops it never works. 1.16.1 on centos7
proxy_set_header X-FORWARDED-FOR # this will do the job

所以你明白了。自定义变量名中不能出现下划线。请改用连字符。

也许 Nginx 在某些语法情况下使用下划线。有人指出官方参考将不胜感激。

Answer 6

这取决于自定义标头的命名方式。我的格式为“SomethingLike.this”，它包含一个点。无法重命名请求中的标头，因为它不是我们的代码。所以这样写是行不通的：

proxy_set_header SomethingLike.this $http_somethinglike.this;
proxy_pass_header  SomethingLike.this;

这也行不通：

underscores_in_headers on;

因为我需要不存在的 dots_in_headers 指令。

但我发现我可以通过添加以下内容来传递所有标头：

ignore_invalid_headers off;

传递所有标头可能不安全，请谨慎使用。