Re: [PATCH v3] t5550: add netrc tests for http 401/403

From: Jeff King <peff@peff.net>
Date: Feb 6, 2026, 20:53 UTC
Message-ID: <20260206205327.GB2787536@coredump.intra.peff.net>
In-Reply-To: <xmqqtsvtg49h.fsf@gitster.g>

On Fri, Feb 06, 2026 at 09:39:54AM -0800, Junio C Hamano wrote:

Show 14 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > I think it is fine to check the 403 handling, but note that this _isn't_
> > how GitHub would respond. If you try to fetch from a repository you
> > don't have access to, it will return a 401 first (so you try to log in)
> > and then a 404. The idea being to avoid revealing the existence of the
> > repository to unauthorized users.
> 
> That is a sensible thing to do on the server side.  Presumably when
> we talk with such a server we would report 404, right?  It is not
> like we behave all that differently with either type of errors---as
> long as we just give up and do not fall into an infinite loop of
> asking "oops, that password did not work, try again", it would be
> OK.

Right, we'd report the 404. We never loop on trying to authenticate, but do a maximum of two tries (and then only if we get a 401 on the first request and did not already provide a credential ourselves to curl). Curl might make multiple requests under the hood for each "try", but we won't even know about them.

And all of that is independent of which HTTP error code was returned (except for 401, obviously). We do eventually produce a different message for 404 vs a 403, but that's at the top-level of remote-curl.c.

The interesting bits are in http_request_reauth(), though some of the logic is in handle_curl_result().

Show 6 quoted lines

> > The netrc support here should not involve credential helpers at all. It
> > is all being done internally by curl.
> 
> Yeah, I phrased my question in a wrong way.  As the code paths
> involving credential helpers are separate, I wondered if we have
> similar test coverage there as well.

The workings are hopefully covered by the explanation above. As far as test coverage, I think t5550 covers this already. When we provide the wrong password, we bail rather than asking repeatedly (e.g., in "cloning password-protected repository can fail").

-Peff