#20120 closed New feature (wontfix)
If DEBUG mode is True and ALLOWED_HOSTS is empty you should get a console warning
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | HTTP handling | Version: | 1.5 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | no |
Description
In Django 1.5, since the ALLOWED_HOSTS is required, the dev server should print a warning to the console on every request while ALLOWED_HOSTS is empty. Otherwise, anyone who misses the new feature will deploy a site to production that doesn't work.
Note: This is different than ticket #19946 and ticket #19866, as those both address the DEBUG=False case. I think having a warning while DEBUG=True will help people avoid running into the problem.
Change History (3)
comment:1 by , 12 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 by , 12 years ago
That's certainly possible, but at least people would be aware of it. I've been using Django since the pre-1.0 days, and while I know I should, I also know that I'm like a lot of developers in that I don't read the release notes for every single new version.
I'd ask you to reconsider. Documentation is rarely a good solution for something that will completely break a site like ALLOWED_HOSTS will.
comment:3 by , 12 years ago
I agree with claudep's resolution of this ticket. It's intentional that you can leave ALLOWED_HOSTS
empty in DEBUG
mode; we shouldn't punish people for doing so with a verbose and frequent warning (every request?). We shouldn't emit warnings unless we expect people to fix them, and the "fix" for this warning makes no sense since the value of ALLOWED_HOSTS
won't be validated anyway in DEBUG
mode.
There are other long-existing settings that are likely to completely break a site if you don't set them correctly in production; DATABASES
, for one. I've never seen someone deploy a new site to production without at least trying one request to see if it works before moving on. If you set DATABASES
wrong, that first request will likely result in an error; the same is true for ALLOWED_HOSTS
. And the error message references the setting name, so if you get the error it shouldn't take too long to find the relevant documentation.
Now, there is a problematic overloading of DEBUG
in the ALLOWED_HOSTS
feature, in that if you don't have logging of production errors set up correctly (i.e. the default email-admins or something else), you won't see the error that tells you why you're getting a 500 on your initial "does my site work" request, and if you flip DEBUG
on temporarily in order to see the error in your browser, the error disappears. I think this is a problem, and I'm not sure what the solution is yet, but I think the solution needs to be focused on that "production isn't working and I don't know why" moment, not spamming the development server console with tons of warnings about a setting that doesn't yet matter to you.
And then you add localhost to
ALLOWED_HOSTS
to silence the warning, and we are back to the original situation.There is now a deployment checklist that is a good reference for building the deployment-ready settings.
https://docs.djangoproject.com/en/dev/howto/deployment/checklist/