http: do not set up curl auth after a 401
authorJeff King <peff@peff.net>
Fri, 12 Oct 2012 07:35:59 +0000 (03:35 -0400)
committerJunio C Hamano <gitster@pobox.com>
Fri, 12 Oct 2012 16:45:15 +0000 (09:45 -0700)
commit1960897ebc5a899a8e4ec3c2afc1d2325574fe41
treedc0b4581c1f0fbbc15a1ff31f3841087800186e7
parentabf8df869c79ee6fa021b117e60683fe149131d8
http: do not set up curl auth after a 401

When we get an http 401, we prompt for credentials and put
them in our global credential struct. We also feed them to
the curl handle that produced the 401, with the intent that
they will be used on a retry.

When the code was originally introduced in commit 42653c0,
this was a necessary step. However, since dfa1725, we always
feed our global credential into every curl handle when we
initialize the slot with get_active_slot. So every further
request already feeds the credential to curl.

Moreover, accessing the slot here is somewhat dubious. After
the slot has produced a response, we don't actually control
it any more.  If we are using curl_multi, it may even have
been re-initialized to handle a different request.

It just so happens that we will reuse the curl handle within
the slot in such a case, and that because we only keep one
global credential, it will be the one we want.  So the
current code is not buggy, but it is misleading.

By cleaning it up, we can remove the slot argument entirely
from handle_curl_result, making it much more obvious that
slots should not be accessed after they are marked as
finished.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
http.c
http.h
remote-curl.c