Django uWSGI NGINX Schlechte Anfrage 400

Question

nach dem Erhalt eines 400-Fehler beim Versuch, meinen Blog, den ich entwickelt habe, mit dem Django-Entwicklungsserver zu starten, startete ich ein neues Testprojekt (mit startproject und nichts weiter tun - nur ein kleine Konfiguration hier und da) - so minimal wie möglich, um es so einfach wie möglich zu halten.

Wenn ich "manage.py runserver" mache, zeigt es mir eine Seite, sagend, dass ich das sehe, weil ich "DEBUG = True" in meinen Einstellungen habe.

So weit so gut. Keine Fehler.

Aber wenn ich uWSGI und NGINX verwende, bekomme ich wieder die "Bad Request (400)" - Seite.

Anfangs hatte ich einige Import-Fehler und ich musste einige Pfade zu sys.path hinzufügen. Aber jetzt bekomme ich keine Fehler von Python, NGINX oder uWSGI und lande immer noch mit der 400-Error-Seite.

Ich habe versucht, die folgenden:

• DEBUG = False
• TEMPLATE_DEBUG = False
• allowed_hosts = [ '*']
• allowed_hosts = '*'
• kommentiert aus der 'django.middleware.clickjacking.XFrameOptionsMiddleware' von MIDDLEWARE_CLASSES
• Verwendung von NGINX mit uWSGI anstelle von Apache mit mod_wsgi (ich steckte wit h dieses Setup, weil ich es mag, aber das hat mein Problem nicht lösen)

Mein Setup: uwsgi, NGINX und der Client (Firefox) laufen aus meinem Notebook (Kubuntu 14.04). Vhost/subdomain (cefk_blawg.localhost), welches sich in der hosts-Datei (cefk_blawg.localhost 127.0.0.1) befindet und korrekt in NGINX konfiguriert wurde (Ich weiß, denn wenn ich ein Pyramidentest-Projekt verwende, funktioniert es tatsächlich wie ein Charme). Es gibt keine Firewall im Weg. Verwendete virtualenv und pip-installed alles darin (django/uwsgi/pillow/mysql-python).

Mein 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 

#

Meine wsgi.py-Datei:

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()) 

Diese meine Anfrage/Antwort, die ich von der LoggingMiddleware in wsgi.py erhalten :

(
    '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: Das war mein nginx-config (Hinweis, dass der Ordner-Name in der Zwischenzeit geändert haben könnte - damit ignorieren, bitte):

# 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

ich aus Ideen bin.

Bitte helfen.

Answer 1

Okay, ich habe den gleichen Fehler, aber ich habe es endlich herausgefunden. (Zumindest für mich). Ich bete zu Gott, dass das für dich funktioniert, weil ich einen Tag damit verschwendet habe.

Wenn Sie wie ich sind, haben Sie: http://uwsgi-docs.readthedocs.org/en/latest/tutorials/Django_and_nginx.html als ein Tutorial verwendet, um die grundlegende Einrichtung zu erhalten. Ich habe uwsgi über http arbeiten und es schien über TCP-Socket zu arbeiten. Sobald ich versuchte, nginx zu verbinden, bekam ich 400 Fehler. Es heißt konkret, erstellen Sie einen Dateinamen my_site.conf und verknüpfen Sie diese mit Websites aktiviert. Nun, wenn Sie Sites aktivieren, sollten Sie eine Datei namens default sehen. Beachten Sie, dass diese Datei nicht default.conf heißt. Versuchen Sie, my_site.conf in my_site umzubenennen und stellen Sie sicher, dass Sie die Verknüpfung erneut herstellen.

TDLR: Verknüpfung my_site.conf aufheben. Benennen Sie my_site.conf in my_site um. Link my_site zu sites-enabled

Answer 2

Sie DEBUG = True auf Ihrem Server festlegen können, starten uwsgi Service und überprüfen Sie die django ‚s Debug-Ausgabe in Ihrem Browser. Die Tatsache, dass Sie mit dem Entwicklungsserver django keine Fehler sehen, bedeutet nicht, dass der Fehler mit den Diensten nginx oder uwsgi zusammenhängt.