[Solved]-Missing custom header with django, nginx and gunicorn

by

7👍

✅

If Django is accessed using uwsgi_pass, then in the appropriate location(s) …

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

If Django is accessed using fastcgi_pass, then in the appropriate location(s) …

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

If Django is accessed using proxy_pass, then in the appropriate location(s) …

# 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;

These should help eliminate the possibility that Nginx is not passing things along from your issue.

👤Dayo

3👍

In your nginx configuration file (f.e. mysite_nginx.conf) in the server section add this parameter: uwsgi_pass_request_headers on;.

For example:

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

    ...

    underscores_in_headers on;
}

And if access to Django goes through uwsgi_pass, you need to add this one parameter uwsgi_pass_request_headers on; in location section.

For example:

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

2👍

I think this is what you need:

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"'

to log what is happening.

You might look deeper into the proxy_set_header section on the upstream proxy module to see how to pass on the headers you need.

You can find the documentation here:

The last entry seems to indicate that nginx passes most headers by default

👤ubiquitousthey

2👍

I didn’t find a real answer, but was able to make a workaround. I was having the same problem with RFC standard headers if-none-match and if-modified-since, so my solution is tested for those headers.

Added to my nginx config:

uwsgi_param HTTP_IF_NONE_MATCH $http_if_none_match;
uwsgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since;

I cannot explain why nginx refuses to pass these headers to uwsgi by default. This config forces it. Pages generate 304s as appropriate now.

For the original question about the non-standard “token” header, this should do the trick:

uwsgi_param HTTP_TOKEN $http_token;
👤Julian

0👍

The answers above are enough for us to figure out the way. But there is still an annoying point we need to know. Yes, it is very annoying.

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

So you get it. Underscore could never appear in the customized variable name. Use a hyphen instead.

Maybe Nginx uses underscores in some grammar cases. Someone pointed out the official reference will be appreciated.

👤W.Perrin

0👍

It depends on how the custom header is named. My was in format "SomethingLike.this", it contains a dot. It was not possible to rename the header in the request, because it is not our code. So writing this would not work:

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

Also this would not work:

underscores_in_headers on;

because I would need dots_in_headers directive which does not exist.

But I found I can pass ALL headers simply by adding:

ignore_invalid_headers off;

It may be insecure to pass all headers, please use with caution.

👤sekrett

Leave a comment