Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Django gives Bad Request (400) when DEBUG = False

Tags:

python

django

I am new to django-1.6. When I run the django server with DEBUG = True, it's running perfectly. But when I change DEBUG to False in the settings file, then the server stopped and it gives the following error on the command prompt:

CommandError: You must set settings.ALLOWED_HOSTS if DEBUG is False. 

After I changed ALLOWED_HOSTS to ["http://127.0.0.1:8000",], in the browser I get the error:

Bad Request (400) 

Is it possible to run Django without debug mode?

like image 593
codeimplementer Avatar asked Nov 09 '13 12:11

codeimplementer


People also ask

What does debug false do Django?

Open your settings.py file (or settings_local.py ) and set DEBUG = False (just add that line if necessary). Turning off the Django debug mode will: Suppress the verbose Django error messages in favor of a standard 404 or 500 error page. You will now find Django error messages printed in your arches.

What does Django debug true do?

The debug mode (DEBUG=True) is turned on by default in the Django framework. It provides a detailed traceback with the local variables to find out the error with the line numbers. The error can be triggered from the view page by setting the value of assert to False in the view file.


2 Answers

The ALLOWED_HOSTS list should contain fully qualified host names, not urls. Leave out the port and the protocol. If you are using 127.0.0.1, I would add localhost to the list too:

ALLOWED_HOSTS = ['127.0.0.1', 'localhost'] 

You could also use * to match any host:

ALLOWED_HOSTS = ['*'] 

Quoting the documentation:

Values in this list can be fully qualified names (e.g. 'www.example.com'), in which case they will be matched against the request’s Host header exactly (case-insensitive, not including port). A value beginning with a period can be used as a subdomain wildcard: '.example.com' will match example.com, www.example.com, and any other subdomain of example.com. A value of '*' will match anything; in this case you are responsible to provide your own validation of the Host header (perhaps in a middleware; if so this middleware must be listed first in MIDDLEWARE_CLASSES).

Bold emphasis mine.

The status 400 response you get is due to a SuspiciousOperation exception being raised when your host header doesn't match any values in that list.

like image 97
Martijn Pieters Avatar answered Sep 20 '22 03:09

Martijn Pieters


I had the same problem and none of the answers resolved my problem. For resolving situations like this, it's best to enable logging by adding the following config to settings.py temporarily.

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,       },    }, } 

When you see the issue, it's easier to handle than by blind debugging.

My issue was:

Invalid HTTP_HOST header: 'pt_web:8000'. The domain name provided is not valid according to RFC 1034/1035.

I resolved it by adding proxy_set_header Host $host; to the Nginx config file and enabling port forwarding with USE_X_FORWARDED_PORT = True in the settings.py (it's because in my case I was listening to requests on Nginx port 8080 and passing to guni on port 8000).

like image 40
Yuseferi Avatar answered Sep 19 '22 03:09

Yuseferi