HTTP push not respecting .netrc

HTTP push not respecting .netrc

[David Borowitz]

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'         <----
> GET http://xxxxx:25989/git/foo/info/refs?service=git-receive-pack HTTP/1.1
> Authorization: Basic zzzzzzzz          <----
> User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
> Host: xxxxx:25989
> Accept: */*
> Proxy-Connection: Keep-Alive
>
< 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

Re: HTTP push not respecting .netrc

[Tay Ray Chuan]

On Thu, Dec 30, 2010 at 2:56 PM, David Borowitz <dave@bwitz.com> wrote:
> 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.)

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

> [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

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

-- 
Cheers,
Ray Chuan

Re: HTTP push not respecting .netrc

[Junio C Hamano]

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

Re: HTTP push not respecting .netrc

[David Borowitz]

On Wed, Jan 12, 2011 at 16:42, Junio C Hamano <gitster@pobox.com> wrote:
> Has this been resolved to satisfaction?  Just being curious...

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.

Re: HTTP push not respecting .netrc

[David Borowitz]

On Wed, Jan 26, 2011 at 18:00, David Borowitz <dave@bwitz.com> wrote:
> But this raises further questions:
> -Why does git/curl decide it's ok to retry with authentication in one
> case, but not in the other?

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).

> -Why does curl send the auth header before ever receiving a 401, while
> git does not? (Would fixing this be as easy as setting another curl
> option?)