url.replace("http://", ...) replaced every occurrence of "http://" in
the fetched URL, including the one inside the "url" query parameter
that RedirectHandler uses as the redirect target. That accidentally
embedded the test credentials in the Location header's URL too, so
the "different origin" subtest was actually exercising "does libcurl
honor credentials the server explicitly put in the redirect target"
rather than "does libcurl strip credentials carried over from the
original request" - libcurl correctly does the former, which is not
a credential leak.
Limit the replacement to the first occurrence so only the outer,
fetched URL carries the test credentials.
Separately, the "same origin" subtest for this case now surfaces an
actual libcurl regression (still present in curl's git master as of
this writing): credentials embedded in the URL are dropped across a
same-origin redirect when the Location header is an absolute URL
(a relative Location correctly preserves them). This isn't a security
issue since nothing leaks to another origin, so that specific
assertion is skipped rather than asserted either way.