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

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

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

> +#ifndef GIT_CURL_HAVE_CURL_URL
> +#define strip_url_credential(in) NULL
> +#else
> +static char *strip_url_credential(const char *in)
> +{
> +	char *ret = NULL;
> +	CURLU *url;
> +
> +	url = curl_url();
> +	if (!url)
> +		goto out;
> +
> +	if (curl_url_set(url, CURLUPART_URL, in, 0))
> +		goto out;
> +
> +	curl_url_set(url, CURLUPART_USER, NULL, 0);
> +	curl_url_set(url, CURLUPART_PASSWORD, NULL, 0);
> +	curl_url_get(url, CURLUPART_URL, &ret, 0);
> +
> +out:
> +	curl_url_cleanup(url);
> +	return ret;
> +}
> +#endif

> > 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?

> > > 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?
> 
> Hmm, interesting. We need to grab the effective URL anyway in order to
> actually do the base-url update. But in theory we could replace the "did
> we redirect at all" early return with a check of the redirect count. And
> indeed, the patch looks much cleaner (see below).
> 
> But sadly, it doesn't work! Curl reports that we did 1 redirect for the
> initial request. I think it is counting the extra request it does for
> the auth (we get a 401, then it auto-retries with the password to get a
> 200).
> 
> So we really do need to do our string-based check for "did the URL
> meaningfully change", and all of the annoying cred-stripping that comes
> with it.
> 
> Too bad, because your solution looks much nicer. ;)