No, the whole problem is a http server (ANY http server, serving ANY content) listening on port 80.

Once the tcp connection is accepted on port 80, "dumb" clients (like curl) can just come barging through the door shouting plaintext auth credentials without knocking first, and no http server can stop them from doing that (because that is how the http protocol works).

The only way to stop them from doing that is rejecting connections on port 80. (Dropping packets looks even more like service outage, which was mentioned.)

The author made this seem outlandish, but really it's a reasonable and easily done way to go about things. Just have a special subdomain for your API (I don't know, api.*.com) and only listen on 443 with it. Done.

That's not enough. The problem is that a client which mistakenly sends a request to Port 80 will send the Authentication request, which, as has already been established, includes (basically) cleartext credentials. Even if whatever you're hosting on Port 80 returns an error, the damage is already done. To prevent that, you have to abort the connection before the client even has a chance to send the request, i.e. closing Port 80.

This means that if you're going to use HTTP Basic authentication, you need to serve your API and your Website from different hosts.

The article covers this: The browser sends the authentication info in the initial request, so by the time the server responds, the damage is already done.