Django donne une requête incorrecte (400) lorsque DEBUG = False
Je suis nouveau sur django-1.6. Lorsque je lance le serveur django avec DEBUG = True, Il fonctionne parfaitement. Mais quand je change DEBUG en False dans le fichier de paramètres, le serveur s'est arrêté et il donne l'erreur suivante sur l'invite de commande:
CommandError: You must set settings.ALLOWED_HOSTS if DEBUG is False.
Après j'ai changé de ALLOWED_HOSTS à ["http://127.0.0.1:8000",], dans le navigateur, j'obtiens l'erreur:
Bad Request (400)
Est-il possible d'exécuter Django sans mode débogage?
6 réponses
Le ALLOWED_HOSTS liste doit contenir pleinement qualifié noms d'hôte, pas url. Quitter le port et le protocole. Si vous utilisez 127.0.0.1, j'ajouterais aussi localhost à la liste:
ALLOWED_HOSTS = ['127.0.0.1', 'localhost']
, Vous pouvez également utiliser * pour correspondre tout hôte:
ALLOWED_HOSTS = ['*']
Citant la documentation:
Les valeurs de cette liste peuvent être des noms complets (par exemple
'www.example.com'), auquel cas elles seront mises en correspondance avec l'en-têteHostde la requête exactement (insensible à la casse, sans compter le port). Une valeur commençant par un point peut être utilisée comme caractère générique de sous-domaine:'.example.com'correspondraexample.com,www.example.com, et tout autre sous-domaine deexample.com. Une valeur de'*'correspondra à n'importe quoi; dans ce cas, vous êtes responsable de fournir votre propre validation de l'en-têteHost(peut-être dans un middleware; si c'est le cas, ce middleware doit être listé en premier dansMIDDLEWARE_CLASSES).
mise en gras de la mine .
La réponse status 400 que vous obtenez est en raison d'un SuspiciousOperation exception étant déclenchée lorsque votre en-tête host ne correspond à aucune valeur de cette liste.
Pour moi, j'ai eu cette erreur en ne définissant pas USE_X_FORWARDED_HOST à vrai. De la docs:
Cela ne devrait être activé que si un proxy qui définit cet en-tête est utilisé.
Mon service d'hébergement a écrit explicitement dans leur documentation que ce paramètre doit être utilisé, et j'obtiens cette erreur 400 si je l'oublie.
J'ai eu le même problème et je l'ai corrigé en définissant ALLOWED_HOSTS = ['*'] et pour résoudre le problème avec les images statiques, vous devez changer les chemins virtuels dans la configuration de l'environnement comme ceci:
Chemin Virtuel
Répertoire
/statique / / opt / python / current / app / yourpj/statique /
/media/ /opt/python/actuel/app/Nuevo/media/
J'espère que ça vous aidera.
PD: désolé pour ma faute anglais.
J'ai eu le même problème et aucune des réponses n'a résolu mon problème, pour résoudre la situation comme celle-ci, il est préférable d'activer la journalisation en ajoutant la configuration suivante à settings.py temporaire
LOGGING = { 'version': 1, 'disable_existing_loggers': False, 'handlers': { 'file': { 'level': 'DEBUG', 'class': 'logging.FileHandler', 'filename': '/tmp/debug.log', }, }, 'loggers': { 'django': { 'handlers': ['file'], 'level': 'DEBUG', 'propagate': True, }, }, }
Et essayez de tail -f /tmp/debug.log.
et quand vous voyez votre problème, vous pouvez le gérer beaucoup plus facilement que le débogage aveugle.
Mon problème était sur le point de
En-tête HTTP_HOST non valide: 'pt_web: 8000'. Le nom de domaine fourni n'est pas valide selon la RFC 1034/1035.
Et résolvez-le en ajoutant proxy_set_header Host $host; au fichier de configuration Nginx et en activant la redirection de port par USE_X_FORWARDED_PORT = True dans le settings.py (c'est parce que dans mon cas j'ai écouté la requête dans Nginx sur le port 8080 et passez-le à guni sur le port 8000
Avec DEBUG = False dans votre fichier de paramètres, vous devez également configurer la liste ALLOWED_HOST.
Essayez d'inclure ALLOWED_HOST = ['127.0.0.1', 'localhost', 'www.yourdomain.com']
Sinon, vous risquez de recevoir une erreur Bad Request(400) de django.
Accédez aux paramètres et recherchez base.py fichier Définissez les hôtes autorisés sur ALLOWED_HOSTS = [ ' *']