If DEBUG mode is True and ALLOWED_HOSTS is empty you should get a console warning

[ty@…]

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.

[Claude Paroz]

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/

[tghw]

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.

[Carl Meyer]

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.