Django uWSGI NGINX Bad Request 400

Question

dopo aver ricevuto un errore 400 durante il tentativo di distribuire il mio blog, che ho sviluppato, utilizzando il server di sviluppo django, ho avviato un nuovo progetto di test (usando startproject e non facendo nient'altro - solo un piccola configurazione qua e là) - il minimo possibile per mantenerlo il più semplice possibile.

Quando faccio "runserver manage.py", mi mostra una pagina, dicendo che vedere questo, perché ho "DEBUG = True" nelle mie impostazioni.

Fin qui tutto bene. Nessun errore

Ma se io uso uWSGI e Nginx, ho la "Bad Request (400)" - pagina di nuovo.

Inizialmente ho avuto qualche importazione-errori e ho dovuto aggiungere alcuni percorsi a sys.path. Ma ora non ottengo errori da python, NGINX o uWSGI e ancora finisco con la 400-Error-page.

ho provato la seguente:

• DEBUG = False
• TEMPLATE_DEBUG = False
• allowed_hosts = [ '*']
• allowed_hosts = '*'
• commentate la 'django.middleware.clickjacking.XFrameOptionsMiddleware' da MIDDLEWARE_CLASSES
• Uso di NGINX con uWSGI invece di Apache con mod_wsgi (ho bloccato lo spirito h questa impostazione, perché mi piace, ma questo non ha risolto il mio problema)

La mia configurazione: uWSGI, Nginx e il client (firefox) corsa da dentro il mio notebook (Kubuntu 14.04). Vhost/sottodominio (cefk_blawg.localhost), che si trova nel hosts file (127.0.0.1 cefk_blawg.localhost) e configurato correttamente in Nginx (lo so, perché quando io uso una piramide-test-progetto, in realtà funziona come un fascino). Non c'è un firewall nel modo. Utilizzato virtualenv e pip ha installato tutto in esso (django/uwsgi/pillow/mysql-python).

miei 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 

#

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

Questa è la mia richiesta/risposta che ricevo dal 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: Questa era la mia nginx-config (avviso, che la cartella-nome potrebbe essere cambiato nel frattempo - in modo da ignorare che, per favore):

# 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

Sono fuori di idee.

prega di aiuto.

Answer 1

Va bene così ho ottenuto questo stesso errore, ma alla fine ho capito. (Almeno per me). Prego Dio che funzioni per te perché ho sprecato un giorno in questo.

Se sei come me hai usato: http://uwsgi-docs.readthedocs.org/en/latest/tutorials/Django_and_nginx.html come tutorial per ottenere la configurazione di base. Ho uwsgi a lavorare su http e sembrava funzionare su socket tcp. Non appena ho provato ad agganciare nginx, ho continuato a ricevere 400 errori. In particolare dice di creare un nome file my_site.conf e collegarlo a siti abilitati. Bene, se controlli l'abilitazione dei siti dovresti vedere un file di default. Si noti che questo file non è denominato default.conf. Prova a rinominare my_site.conf su my_site e assicurati di ricollegare.

TDLR: Scollegare my_site.conf. Rinomina my_site.conf a my_site. Collegamento my_site ai siti abilitati

Answer 2

È possibile impostare DEBUG = True sul server, riavviare uwsgi servizio e controllare l'output di debug 's il django nel browser. Il fatto che non si vedano errori con il server di sviluppo django non significa che l'errore è correlato ai servizi nginx o uwsgi.