Re: [PATCH] http: handle curl stripping creds from effective url

[Patrick Steinhardt <ps@pks.im>]

On Mon, Sep 28, 2026 at 12:01:49AM -0400, Jeff King wrote:
> When we detect that curl performed a redirect of a URL we requested, we
> update our base URL to match the new location and flush the http_auth
> credentials. This goes back to c93c92f309 (http: update base URLs when
> we see redirects, 2013-09-28).
> 
> We detect the redirect by comparing the requested URL to the response
> from CURLINFO_EFFECTIVE_URL, using a simple string comparison. This has
> worked fine for years, but a change in the upcoming curl 8.23.0 adds a
> complication. If our URL directly contains credentials (like
> "https://user:pass@example.com/foo.git"), then as of 7a6bd027d0
> (getinfo: make sure CURLINFO_EFFECTIVE_URL does not contain creds,
> 2026-09-21), curl will strip the credentials from what it returns (so
> just "https://example.com/foo.git" in this case).
> 
> This breaks our direct string comparison, and we believe that we've been
> redirected. We flush our http_auth credentials, and now subsequent
> requests will use the reduced URL, causing us to re-request credentials
> from the user. Notably this causes t5550.15 (among others) to complain;
> it tries a clone with credentials in the URL, and fails if the user is
> prompted at all.
> 
> We can handle this new behavior by doing a more careful comparison: if
> the direct string comparison fails, we'll strip out the credentials
> ourselves and compare. This is a little extra work, but in practice it
> should only happen once per process.

So in my own words, we want to detect the case where we have been
redirected and, if we have been, we want to strip credentials. But this
logic is about to break as curl starts to rewrite EFFECTIVE_URL more
aggressively, and that makes us detect redirects in cases where there
were none.

> I've used curl's curl_url() interface to do the stripping here, mostly
> because its behavior should match the stripping it does internally. And
> also, though we have code to parse a URL, we don't have any to
> reconstruct it, making a single string comparison hard.
> 
> One alternative would be to parse with url_parse() or similar, and
> compare the individual fields (skipping username/password). I think that
> would probably also work in practice, but it seemed to me that the
> simplest change would be sticking with string comparisons.

It still feels rather roundabout to compare URLs only to figure out
whether we have been redirected. I wondered whether there is maybe a
more direct way to get that info, and there indeed is
CURLINFO_REDIRECT_COUNT, which allows us to retrieve the number of
redirects that have happened.

Is that interface maybe a more direct way to get what we're after?

Patrick