Currently Git only sends authentication over HTTP once it's received a 401 response from the server. This series allows users to indicate that they (or the credential helper) know what kind of authentication is to be performed and avoid the extra round trip. This has a couple of use cases: * Some connections are high-latency or potentially unreliable and the extra round trip is expensive or flaky, so avoiding it can be desirable. * Users can authenticate even to public repositories for fetches and clones, such as to access higher rate limits or to allow better identification of the requesting party. This can be useful to help identify, say, an internal service that is requesting excessive amounts of resources and throttle it appropriately. (An incident involving this very situation is the impetus for this series.) * Some environments have very unusual proxy setups which require all requests to be authenticated, and this might be useful there. (This is not a goal of this series and not a problem I'm generally interested in solving, but it happens to benefit those people as well, so I thought I'd mention it.) Note that the types of authentication for which we can do proactive auth are relatively limited. Of the standard forms provided by libcurl, I believe only Basic is possible, because the others require a nonce or challenge from the server that is used in the computation of the authentication value. Due to the new credential functionality recently introduced, Bearer is also a useful possibility. brian m. carlson (1): http: allow authenticating proactively Documentation/config/http.txt | 15 +++++ http.c | 59 +++++++++++++++-- t/t5563-simple-http-auth.sh | 116 ++++++++++++++++++++++++++++++++++ 3 files changed, 184 insertions(+), 6 deletions(-)
