Django uWSGI NGINX Bad Request 400

after receiving 400 errors while trying to deploy my blog, which I developed using the django development server, I started a new test project (using startproject and doing nothing - just a small configuration here and there) - as little as possible in order to simplify it as much as possible.

When I do "manage.py runningerver", it shows me the page, saying that I see it because I have "DEBUG = True" in my settings.

So far so good. No mistakes.

But if I use uWSGI and NGINX, I get the "Bad Request (400)" page again.

Initially, I had some import errors, and I had to add some paths to sys.path. But now I am not getting errors from python, NGINX or uWSGI and am still finishing the page with 400 errors.

I tried the following:

  • DEBUG = False
  • TEMPLATE_DEBUG = False
  • ALLOWED_HOSTS = ['*']
  • ALLOWED_HOSTS = '*'
  • Comments on "django.middleware.clickjacking.XFrameOptionsMiddleware" of MIDDLEWARE_CLASSES
  • Using NGINX with uWSGI instead of Apache with mod_wsgi (I stuck with this setting because I like it, but that didn't solve my problem)

My setup: uWSGI, NGINX and the client (firefox) are launched from my laptop (kubuntu 14.04). Vhost / subdomain (cefk_blawg.localhost), which is in the hosts file (cefk_blawg.localhost 127.0.0.1) and correctly configured in NGINX (I know, because when I use the pyramid test project, it really works like a charm). There is no firewall in this way. Used virtualenv and pip-installed everything in it (django / uwsgi / pillow / mysql-python).

My uwsgi.ini:

[uwsgi] # Unix socket (full path) socket = /tmp/cefk_blawg.sock # Set socket permissions chmod-socket = 666 # Master process master = true # Maximum number of worker processes processes = 4 # Set timeout harakiri = 60 harakiri-verbose = true # Limit post-size limit-post = 65536 # When to start buffering for post-vars post-buffering = 1 ## none of these makes my problem go away #post-buffering = 8192 ## none of these makes my problem go away #post-buffering = 32768 ## none of these makes my problem go away # Daemonize daemonize = /home/cefk/Dokumente/cefk_blawg/uwsgi.log pidfile = /home/cefk/Dokumente/cefk_blawg/uwsgi.pid # Limit queue listen = 64 max-requests = 1000 # Whatever this does .. it works for pyramid (got it from a tutorial) reload-on-as = 128 reload-on-rss = 96 no-orphans = true log-slow = true # This is the full path to my virtualenv virtualenv = /home/cefk/Dokumente/cefk_blawg/venv # Django wsgi file wsgi-file = /home/cefk/Dokumente/cefk_blawg/cefk_info/cefk_info/wsgi.py # Settings file (this seems to do nothing) # And it gets set in the wsgi.py-file env = DJANGO_SETTINGS_MODULE=cefk_info.settings # Set domain (this seems to do nothing) #domain = cefk_blawg.localhost # Django-project base directory (this seems to do nothing) #chdir = /home/cefk/Dokumente/cefk_blawg/cefk_info # This seems to do nothing #pythonpath=/home/cefk/Dokumente/cefk_blawg/cefk_info/cefk_info/ # Set vhost (this seems to do nothing) #vhost = true # Clean up environment on exit vacuum = true 
#

My wsgi.py file:

 import os import pprint import site import sys from django.core.wsgi import get_wsgi_application base_parent = '/home/cefk/Dokumente/cefk_blawg/' base = '/home/cefk/Dokumente/cefk_blawg/cefk_info/' sys.path.append(base_parent) sys.path.append(base) site.addsitedir( '/home/cefk/Dokumente/cefk_blawg/venv/local/lib/python2.7/site-packages' ) os.environ.setdefault("DJANGO_SETTINGS_MODULE", "cefk_info.settings") activate_env = '/home/cefk/Dokumente/cefk_blawg/venv/bin/activate_this.py' execfile(activate_env, dict(__file__=activate_env)) # I stole this shamelessly from another stackoverflow-post - this is good to have class LoggingMiddleware: def __init__(self, application): self.__application = application def __call__(self, environ, start_response): errors = environ['wsgi.errors'] pprint.pprint(('REQUEST', environ), stream=errors) def _start_response(status, headers, *args): pprint.pprint(('RESPONSE', status, headers), stream=errors) return start_response(status, headers, *args) return self.__application(environ, _start_response) application = LoggingMiddleware(get_wsgi_application()) 

This is my request / response that I get from LoggingMiddleware in wsgi.py:

 ( 'REQUEST', { 'CONTENT_LENGTH': '', 'CONTENT_TYPE': '', 'DOCUMENT_ROOT': '/home/cefk/Dokumente/cefk_blawg/cefk_info/cefk_info', 'HTTP_ACCEPT': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8', 'HTTP_ACCEPT_ENCODING': 'gzip, deflate', 'HTTP_ACCEPT_LANGUAGE': 'de,en-US;q=0.7,en;q=0.3', 'HTTP_CACHE_CONTROL': 'max-age=0', 'HTTP_CONNECTION': 'keep-alive', 'HTTP_DNT': '1', 'HTTP_HOST': 'cefk_blawg.localhost', 'HTTP_USER_AGENT': 'Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0', 'PATH_INFO': '/', 'QUERY_STRING': '', 'REMOTE_ADDR': '127.0.0.1', 'REMOTE_PORT': '42518', 'REQUEST_METHOD': 'GET', 'REQUEST_URI': '/', 'SERVER_NAME': 'cefk_blawg.localhost', 'SERVER_PORT': '80', 'SERVER_PROTOCOL': 'HTTP/1.1', 'UWSGI_SCHEME': 'http', 'uwsgi.node': 'lt', 'uwsgi.version': '2.0.5.1', 'wsgi.errors': <open file 'wsgi_errors', mode 'w' at 0x7ff4337110c0>, 'wsgi.file_wrapper': <built-in function uwsgi_sendfile>, 'wsgi.input': <uwsgi._Input object at 0x7ff437271e70>, 'wsgi.multiprocess': True, 'wsgi.multithread': False, 'wsgi.run_once': False, 'wsgi.url_scheme': 'http', 'wsgi.version': (1, 0) } ) ('RESPONSE', '400 BAD REQUEST', [('Content-Type', 'text/html')]) [pid: 2652|app: 0|req: 1/1] 127.0.0.1 () {42 vars in 675 bytes} [Thu Jun 12 17:16:59 2014] GET / => generated 26 bytes in 150 msecs (HTTP/1.1 400) 1 headers in 53 bytes (1 switches on core 0) 

EDIT: This was my nginx-config (note that the folder name could be changed at the same time - so ignore this):

 # Server configuration server { # Make site accessible from http://cefk_blawg.localhost/ server_name cefk_blawg.localhost; root /home/cefk/Dokumente/cefk_blawg_django; # Set charset charset utf-8; client_max_body_size 100M; location /static { autoindex on; alias /home/cefk/Dokumente/cefk_blawg_django/static; } location /media { autoindex on; alias /home/cefk/Dokumente/cefk_blawg_django/media; } ################################ # Port-based (old) # ################################ #location / { # try_files $uri @application; #} #location @application { # include /etc/nginx/uwsgi_params; # uwsgi_pass 127.0.0.1:8000; #} ################################ # /Port-based (old) # ################################ location / { include /etc/nginx/uwsgi_params; uwsgi_pass unix:///tmp/cefk_blawg.sock; } } 

/ EDIT

I have no ideas.

Please, help.

+9
source share
4 answers

Since I asked this question more than 5 years ago, I could be wrong. But now I will try to answer it as best as possible, since all the answers that appear seem far from my decisions.

I recently used Django again for several projects, and I had a similar problem.

List of what I did wrong:

  • Is uwsgi installed on virtualenv as well as globally on the system
  • Incorrect application path in uwsgi-config
  • Wrong path to virtualenv in uwsgi-config
  • Socket file permissions for uwsgi and nginx connections were set incorrectly

That’s all I can think about what I’m doing wrong, back that day.

I hope this helps everyone struggling with customization.

+1
source

You can install DEBUG = True on your server, restart the uwsgi service and check the output of django debugging in your browser. The fact that you do not see errors with the django development server does not mean that the error is related to nginx or uwsgi services.

+8
source

In settings.py

 ALLOWED_HOSTS = ['*'] 

Solve it

+3
source

Ok, so I got the same error, but finally understood. (At least for me). I pray to God that this works for you because I spent a day on it.

If you are like me, you used: http://uwsgi-docs.readthedocs.org/en/latest/tutorials/Django_and_nginx.html as a tutorial for getting the basic setup. I got uwsgi to work on http and it seems to have worked on tcp socket. As soon as I tried to connect nginx, I kept getting 400 errors. It specifically indicates the creation of the file name my_site.conf and a link to sites with included. Well, if you check the sites, you should see a file called default. Note that this file does not have the name default.conf. Try renaming my_site.conf to my_site and make sure you reconnect.

TDLR: Unlink my_site.conf. Rename my_site.conf to my_site. Link my_site to sites

+1
source

Source: https://habr.com/ru/post/970772/


All Articles