Django uWSGI NGINX Złe żądanie 400

Question

po otrzymaniu błędu 400 przy próbie wdrożenia mojego bloga, który opracowałem, przy użyciu serwera deweloperskiego django, rozpocząłem nowy test-projekt (używając startproject i nie robiąc nic innego - po prostu mała konfiguracja tu i tam) - tak minimalna, jak to tylko możliwe, aby była jak najprostsza.

Kiedy robię "manage.py runserver", pokazuje mi stronę, mówiąc, że to widzę, ponieważ w ustawieniach mam "DEBUG = True".

Jak dotąd tak dobrze. Bez błędów.

Ale jeśli używam uWSGI i NGINX, ponownie otrzymuję stronę "Bad Request (400)".

Początkowo miałem kilka błędów importu i musiałem dodać kilka ścieżek do sys.path. Ale teraz nie dostaję żadnych błędów z Pythona, NGINX lub uWSGI i nadal kończę na 400-stronie błędu.

Próbowałem następujące:

• DEBUG = False
• TEMPLATE_DEBUG = False
• ALLOWED_HOSTS = [ '*']
• ALLOWED_HOSTS = '*'
• wypowiedziało się "django.middleware.clickjacking.XFrameOptionsMiddleware" z MIDDLEWARE_CLASSES
• Używanie NGINX z uWSGI zamiast Apache z mod_wsgi (mam problem h ta konfiguracja, bo lubię go, ale to nie rozwiązuje mojego problemu)

Moja konfiguracja: uWSGI, Nginx, a klient (firefox) prowadzony od wewnątrz moim notebooku (Kubuntu 14.04). Vhost/subdomena (cefk_blawg.localhost), która znajduje się w pliku hosts (cefk_blawg.localhost 127.0.0.1) i poprawnie skonfigurowana w NGINX (wiem, ponieważ kiedy używam projektu testu piramidowego, to faktycznie działa jak urok). Nie ma zapory na drodze. Używane virtualenv i pip-installed wszystko w nim (django/uwsgi/pillow/mysql-python).

Moi 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 

#

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

To jest moje żądanie/odpowiedź, które dostaję od LoggingMiddleware w 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: To był mój nginx-config (Zauważ, że folder nazwa mogła ulec zmianie w międzyczasie - tak zignorować, proszę):

# 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

jestem z pomysłów.

Proszę o pomoc.

Answer 1

Okej, więc dostałem ten sam błąd, ale w końcu to rozgryzłem. (Przynajmniej dla mnie). Modlę się do Boga, że ​​to działa dla ciebie, ponieważ zmarnowałem dzień na to.

Jeśli jesteś podobny do mnie, użyłeś: http://uwsgi-docs.readthedocs.org/en/latest/tutorials/Django_and_nginx.html jako samouczek, aby uzyskać podstawowe ustawienia. Dostałem uwsgi do pracy przez http i wydawało się, że działa na gniazdku tcp. Jak tylko próbowałem podłączyć nginx, ciągle otrzymywałem 400 błędów. Mówi w szczególności o utworzeniu nazwy pliku my_site.conf i powiązaniu z witryną. Cóż, jeśli zaznaczysz włączone witryny, powinieneś zobaczyć plik o domyślnej nazwie. Zauważ, że ten plik nie ma nazwy default.conf. Spróbuj zmienić nazwę pliku my_site.conf na my_site i ponownie dodaj link.

TDLR: Rozłączenie pliku my_site.conf. Zmień nazwę pliku my_site.conf na my_site. Połącz moją stronę z witryną obsługującą

Answer 2

Możesz ustawić DEBUG = True na swoim serwerze, ponownie uruchomić usługę uwsgi i sprawdzić dane wyjściowe debugowania django w przeglądarce. Fakt, że nie widzisz żadnych błędów na serwerze rozwojowym django nie oznacza, że ​​błąd jest związany z usługami nginx lub uwsgi.