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

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

Jeff King [off-list ref] writes:

quoted

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

quoted

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