Mon 01 Sep 2014 08:49:23 AM UTC, comment #1:
Hi,
Thanks for your bug report. However, the issue you describe is there by design and is not considered a flaw.
When you put the username and password in the URL, Wget assumes that those credentials are valid for the particular file alone and not everything else on the server. This is the reason why Wget has an explicit check to see if the credentials were provided in the URL itself. In that scenario, we do not store the credentials globally and the server is not appended to basic_authed_hosts.
The issue in fact occurs due to a mis-configured server on your end. I came to this conclusion based on the debug logs that you provided. Let me explain further:
I'm going to use the problematic log, Wget_log_withPasswordInUrl.txt. In this log file, Wget first sends a normal HTTP GET request to the server, with a "Connection: Keep-Alive" Header. The response to the request is a 401 Authorization Required with no "Connection" header. Hence, Wget assumes a persistent connection and continues. This behavior of Wget is based on RFC 7230 sec. 6.1 and the erstwhile specification RFC 2616 too, which states, 'A server that does not support persistent connections MUST send the "close" connection option in every response message that does not have a 1xx Informational) status code.'
When Wget realizes that the connection was closed, it attempts to start a new connection. But by this time all the previous state information in Wget has been lost. It initiates a new connection and goes through the dance again. However, if the server were to simply send a "Connection: Close" header as is mentioned in the HTTP Specification, Wget would store the details and ensure that the authorization header is indeed sent even when it needs to open a new connection.
If you have any more issues / need more information about this issue, please do not hesitate to ask. However, I don't think we'll be changing how Wget functions based on this bug report.
|