Description of problem: wget-1.11.1-1.fc9.i386 seems to ignore --http-user and --http-password command-line parameters, not sending Authentication HTTP header. Version-Release number of selected component (if applicable): 1.11.1-1 How reproducible: Two different i386 hosts tested, exactly same results. Steps to Reproduce: 1. Just use wget --http-user=<user> --http-password=<password> to localhost on some port you listen with nc (error is not restricted to localhost anyway). Authentication header won't arrive. Actual results: (with wget-1.11.1-1.fc9.i386) GET / HTTP/1.0 User-Agent: Wget/1.11.1 (Red Hat modified) Accept: */* Host: localhost:8001 Connection: Keep-Alive Expected results: (with wget-1.10.2-16.fc8) GET / HTTP/1.0 User-Agent: Wget/1.10.2 (Red Hat modified) Accept: */* Authorization: Basic bWF4Om1pbg== Host: localhost:8001 Connection: Keep-Alive Additional info:
This is not a bug. Clients should never send authentication headers before receiving a challenge from the server. Among other reasons, this means sending the password in cleartext, easily snooped by anyone between you and the server (unless you're on an SSL connection; but even then it's inappropriate to assume what authentication mechanism the server wants before it asks). The server might well request Digest auth or some other, much more secure authentication mechanism. This fix was introduced in 1.11. However, there are some rare cases where the old behavior is still desirable (for instance, servers that don't issue challenges because they normally use form authentication, but support Basic auth as an alternative way to authenticate). If this is you, then see the --auth-no-challenge, which was introduced in 1.11.1, and restores the previous broken behavior from 1.10.2. See also RFC 2617 (with which Wget still doesn't properly comply, but at least it's a step closer).