On Wed, Oct 22, 2008 at 12:47:32AM +0200, Josef Wolf wrote:
> Yes, I see. The problem is that this breaks the challenge-response
> mechanism described in rfc2617.

It doesn't break anything if you only want to send a user name with an
empty password, which is what that command-line is requesting.

> Hmm, what is the fundamental difference that causes curl to ask for
> password in one case but not in the two cases above? Is there a
> rationale for handling it this way? Are the other authentication
> mechanisms handled in the same way?

curl offers two ways to set credentials--within the URL and outside the
URL. When specified within the URL, it assumes the credentials are complete
and doesn't ask the user for anything more. When set outside the URL, it
will ask the user for a password when one isn't supplied. That just how
curl does it.
>
> IMHO, this is very impractical: often URLs are specified on command
> line, revealing the password to everyone who can run ps.

It's impractical in some situations, but essential in others. Which is
why curl offers several ways to do it.
>
> So to mimic the behavior of a web browser, the application (git in this
> case) should be able to recognize the 401, find out the realm, and
> finally repeat the request.

Exactly. And it sounds like it's not doing so right now.

>>> Dan

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved