I didn't find anywhere what was a motivation of developers to introduce the Basic Auth challenge mechanism was introduced except of that "it imitates the web browser experience". My only guess is that this is needed to allow to server to set some cookie but I'm pretty sure that that wasn't a real case.

I would like to ask you to reconsider this because in fact it makes almost no sense for security reason but create an additional network load instead and confusion for users who got an error.

The only documentation about that descibes the Auth challenge mode is:

> ‘--auth-no-challenge’
>  If this option is given, Wget will send Basic HTTP authentication information (plaintext username and password) for all requests, just like Wget 1.10.2 and prior did by default.
> Use of this option is not recommended, and is intended only to support some few obscure servers, which never send HTTP authentication challenges, but accept unsolicited auth info, say, in addition to form-based authentication.

So let's think about the attack vector and how the auth challenge flow protects us.
1. If the original sever stopped to ask for auth this may happens because of few reasons:
  * the API is not protected anymore and become public (low possibility). In this case it's ok show credentials because the just not needed anymore.
  * the API endpoint was moved somewhere else (version change) or it was removed at all. In this case it's also fine to send credentials but wget will receive 404 or 302 error.

In both cases an attacker can get an access to server's access logs and see the Authorization header with credentials but in any case if the  the original server was written correctly will not show the Authorization header in logs. But if the API is really requires credentials then the same situation.


2. If the original server gone (it's domain expired, service closed etc.) and now there is some another server with the same URL then there is two possibility:

• The new server with the same URL belongs to an attacker: then it will just imitate the API and ask for the Basic Auth as previous service did and send WWW-Realm header. So the auth challenge won't help in this case.
• The new service is non frauding then they just receive the Authorization header but they won't do anything with it.

In both cases credentials are leaked to someone else but anyway the original server is not exists anymore so there is not a big deal. Except of if your password is the same on other sites but here nobody can help you.

3. An attacker sitting on a wire (MITM). The HTTPS protects from this. But even for HTTP an attacker will see your credentials on successful API call. In case if the call wasn't successful this means that original server gone as I described in situation 2.

So, in fact the Auth challenge doesn't protect credentials in any case. Then why to do this?

The problem is that "some few obscure servers" are in fact not so few and one of them is for example GitHub OAuth server. I can't retrieve user info from GH OAuth because it doesn't sends the realm on first request.
So I lost some time of my life trying to figure out what was wrong. You may found in internet forums that there is a lot of people who faced the similar issue.
Another issue is that this violates Postel's law: "be conservative in what you do, be liberal in what you accept from others".
But what is even more important is that this creates an additional load to client, network and servers and gives absolutely nothing.
For example I wanted to call the GitHub's API from embedded device which is very slow and with limited resources and bad connectivity over wifi. And I was unpleasantly surprised that in fact all my API calls are made two times: one for the challtnge and another a real useful call.

Please disable the Auth challenge mode or even remove it from wget. I'm pretty sure that nobody will miss it.