HTTP push not respecting .netrc

Hi all,

I'm trying to push to a smart HTTP remote using the following command line: http_proxy=localhost:4242 git push -v http://xxxxx:25989/git/foo +refs/heads/*:refs/heads/* (The weird proxy and port are not under my control.)

The webserver should return 401 for unauthorized access, and indeed it does: error: RPC failed; result=65, HTTP code = 401 (The rest of the error text from git push is not particularly useful, but I'm not worried about that at the moment.)

Making a request manually with curl --netrc shows that the auth header is being sent[1]. But sniffing the HTTP traffic from git shows that the auth header is not sent[2].

I also tried various other things like aliasing xxxxx to 127.0.0.1 and removing the proxy and port number, and specifying user@xxxxx in the URL, and nothing I've done makes git send the necessary auth header. (In the last case it does prompt for a password.)

Anyone have any other ideas? I could swear this was working a few weeks ago, so I must be missing something simple.

[1]
$ http_proxy=localhost:4242 curl -vvn
http://xxxxx:25989/git/foo/info/refs?service=git-receive-pack
* About to connect() to proxy localhost port 4242 (#0)
*   Trying ::1... Connection refused
*   Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 4242 (#0)
* Server auth using Basic with user 'yyyyy'         <----

< HTTP/1.1 200 OK ...

[2]
GET http://xxxxx:25989/git/foo/info/refs?service=git-receive-pack HTTP/1.1
User-Agent: git/1.7.4.rc0
Host: xxxxx:25989
Accept: */*
Proxy-Connection: Keep-Alive
Pragma: no-cache

On Thu, Dec 30, 2010 at 2:56 PM, David Borowitz <dave@bwitz.com> wrote:

Could you run the push with the environment variable GIT_CURL_VERBOSE=1?

Try having a entry for xxxxx:25989 in your .netrc - that should be sufficient to demonstrate to you that git+curl reads your .netrc.

Has this been resolved to satisfaction?  Just being curious...

On Wed, Jan 12, 2011 at 16:42, Junio C Hamano <gitster@pobox.com> wrote:

I went on vacation, came back, and it magically worked (or maybe I typed something else); you know how these things can be. I'll definitely use those tips and respond on this thread if it happens again.

On Wed, Jan 26, 2011 at 18:00, David Borowitz <dave@bwitz.com> wrote:

Poking further, it looks like curl is deciding not to retry because the ioctl callback is failing to rewind the post buffer when clearly it should be able to. So it's more likely a git bug than a curl issue (the following question notwithstanding).