How nice. We apparently have been using invalid IP addresses in our tests. Well, now we can clean that up too.

So ipaddress.ip_address does not accept the square brackets when validating an IPv6 address. However, the user should supply them as they are required in a URL and dev_addr includes the port so that is a URL. Need to add some additional logic for that. In other words, the failing tests are correct. The validation needs to be adjusted so that the tests pass.

This is getting weirder.

$ mkdocs serve -a [::1]:8000
INFO    -  Building documentation...
INFO    -  Cleaning site directory
INFO    -  Documentation built in 1.22 seconds
INFO    -  Serving on http://[::1]:8000

[Errno 8] nodename nor servname provided, or not known
$ mkdocs serve -a ::1:8000
INFO    -  Building documentation...
INFO    -  Cleaning site directory
INFO    -  Documentation built in 1.18 seconds
INFO    -  Serving on http://::1:8000
INFO    -  Start watching changes
INFO    -  Start detecting changes

[::1]:8000 causes the server to error out, but ::1:8000 works fine. However, with the server running at ::1:8000, from the browser, http://[::1]:8000 works, but http://::1:8000 fails.

@waylan This change complicates local development with docker containers. Why do you care what IP address user can get there? It's user responsibility and decision.

@waylan This change complicates local development with docker containers. Why do you care what IP address user can get there? It's user responsibility and decision.

Complicates? Do you have a workaround already?

Why do you care what IP address user can get there?

As has been explained many times, we do not support using our server for anything except on the local device. Using 0.0.0.0 allows people to use the server outside of what we support and leads to a constant stream of support requests to for help in addressing problems with their setup. By disallowing 0.0.0.0 and displaying a message explaining it is not supported, the idea was that this would lessen the misguided requests from users.

@waylan This change complicates local development with docker containers. Why do you care what IP address user can get there? It's user responsibility and decision.

I am also a user negatively impacted by this decision because I run mkdocs serve inside of Docker containers for my local development workflow. This simplifies our workflow by reducing the number of dependencies on the developer system. I then have a wrapper script around docker run that uses --mount to expose my source files into the container, which the server will then see changes live. I get the best of both worlds: edit the files on my local machine while using Docker for managing dependencies.

The only workaround that I have right now is to use host mode (--network host) when running the server. The problem with this solution is that:

1. The container now has the ability to query services running on my local host and I have lost network isolation for the code running in the container.
2. I cannot remap ports from inside the container to be different ports outside my container. This prevents, for example, the ability to run multiple development servers on the same host.

For production, I have a workflow that builds the static site and hosts via Nginx.

Of course, the other obvious workaround is pip install mkdocs==1.1.

The conversation regarding this change is in #2108. Please follow up there.