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

[Patrick Steinhardt <ps@pks.im>]

On Mon, Sep 28, 2026 at 03:36:44PM -0400, Jeff King wrote:
> On Mon, Sep 28, 2026 at 03:01:07PM +0200, Patrick Steinhardt wrote:
[snip]
> > > 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. ;)

Oh, well, that really is too bad indeed. Anyway, let's go with your
first version in that case. Thanks!

Patrick