Technically this could just be done in the docker settings because I think it's only related to running with docker due to the docker network.

I agree with @marksweb , what is the purpose of changing this part?

I couldn't find a case where we need to keep a whitelist of hosts for development purposes

The purpose is to remove a broken setting that creating extra complexity with no benefit; refactoring.

I think it's only related to running with docker due to the docker network.

0.0.0.0 is not related to the Docker network.

Have you run the site with this configuration, accessed all of the different domains listed in the file, and confirmed that they display the appropriate site?

If the proper host name is not getting through to Django, it seems like the problem needs to be fixed somewhere else.

I tried the Docker instructions, and I think the issue is the README. "View the site at http://localhost:8000/" should be updated to show the correct domains, which can be found at the end of the non-Docker instructions ("http://www.djangoproject.localhost:8000/, http://docs.djangoproject.localhost:8000/, or http://dashboard.djangoproject.localhost:8000/.").

The reference to 0.0.0.0:8000 in the README is for Foreman (I am not familiar with this), but I suspect it's wrong and should be removed or updated as well.

Working for me with Docker and the correct domain, and no local changes:

@tobiasmcnulty Yes, there is a workaround, but once again, the point is to remove a setting that doesn't provide any benefit. I'm missing what is recommended in this thread. Are you saying "we don't need to allow 0.0.0.0"? If that's the case, I see no reason to block it, and the instructions can be updated (and will be updated, because Docker setup is not ready to use yet). If your point is "we don't need refactoring", I don't think not improving a config is a good thing. In any case, I need to ask for actionable insight.

About foreman, not sure why you think it's wrong but accessing a local project over 0.0.0.0, 127.0.0.1 or localhost is common practice, which I see no issue in having mentioned in a doc. Having the mention of foreman, and the procfile in the repo, is something I'd like to discuss but that would be a separate refactoring discussion.

As I said before, my recommendation is to update the README. This is not a workaround; these are the actual domains you need to use to access the development site, as listed in the README, the ALLOWED_HOSTS setting, the dev_sites fixture, and the django-hosts configuration (djangoproject/hosts.py). They're also the domains used by the test suite. It's the same for the non-Docker setup, and the ALLOWED_HOSTS settings helps you see that you're not using the development server as it was intended.

If you would like to propose a change to allow the main site to be access on localhost:8000 instead of or in addition to www.djangoproject.localhost:8000, the change deserves its own issue where the @django/django-website team and others who work on the site can discuss and decide how to move forward.

Thanks for the clarification. So, we need developers to access the project locally via specific hostnames 👍🏻 Blocking undesired hosts via ALLOWED_HOSTS provides only a partial solution for that need and creates further confusion. It blocks access in particular scenarios, but it doesn't help to find the right entry points or provide any information that the developer is doing something undesired. I think a better solution could be to apply the changes in this PR, and then follow up with forwarding requests from common entry points, such as "0.0.0.0" and "127.0.0.1", to the desired hostnames. I'll create an issue to have a healthier discussion 🌻