Invalid URL parsing on logging on ConfigServerConfigurationProvider.cs:570

[pitermarx]

Describe the bug

In ConfigServer Configuration, if I have a comma separated list of Env/Profiles I get an exception from new Uri()

Steps to reproduce

Assuming I have this configuration

{
  "Spring": {
    "Application":{
      "Name": "sample"
    },
    "Cloud": {
      "Config": {
        "Uri": "http://localhost:8888",
        "Env": "local,staging"
      }
    }
  }
}

ConfigServerConfigurationProvider.cs:570 will throw due to an exception on UriExtensions.ToMaskedString
Even though config server itself allows multiple profiles, the string.split(',') doesn't really make sense

https://github.com/SteeltoeOSS/Steeltoe/blob/main/src/Configuration/src/ConfigServer/ConfigServerConfigurationProvider.cs#L570

https://github.com/SteeltoeOSS/Steeltoe/blob/main/src/Common/src/Common/Extensions/UriExtensions.cs#L20

public static string ToMaskedString(this Uri source)
    {
        ArgumentNullException.ThrowIfNull(source);

        string uris = source.ToString();

        if (uris.Contains(','))
        {
            return string.Join(',',
                uris.Split(',', StringSplitOptions.RemoveEmptyEntries | StringSplitOptions.TrimEntries).Select(uri => ToMaskedUri(new Uri(uri)).ToString()));
        }

        return ToMaskedUri(source).ToString();
    }

Expected behavior

I expect that the result from config server is returned, and that logging the request does not make the configuration load fail.

Environment (please complete the following information):

• Steeltoe Version 4.0.0-rc1
• Platform: ANY
• OS: ANY
• .NET Version net8.9

Additional context or links

https://github.com/SteeltoeOSS/Steeltoe/blob/main/src/Configuration/src/ConfigServer/ConfigServerConfigurationProvider.cs#L570

https://github.com/SteeltoeOSS/Steeltoe/blob/main/src/Common/src/Common/Extensions/UriExtensions.cs#L20

[TimHess]

Thanks for the report @pitermarx, I agree this behavior is unexpected and undesired...

It looks like there were two the related code changes in #1327:

1. calling ToMaskedUri on the config server URI (instead of logging it directly)
2. adding the split on commas (as you already pointed out)

This method is called from several places, and in some cases there could be basic auth credentials included in one or more of the URIs, so we shouldn't remove the splitting entirely and probably need to make it optional

[pitermarx]

I took a quick look and I also was unsure from the usages. On the other hand the input is an URI object, so I question the validity of splitting

…

________________________________ From: Tim Hess ***@***.***> Sent: Tuesday, August 12, 2025 8:09:56 PM To: SteeltoeOSS/Steeltoe ***@***.***> Cc: ριтєя мαяχ ***@***.***>; Mention ***@***.***> Subject: Re: [SteeltoeOSS/Steeltoe] Invalid URL parsing on logging on ConfigServerConfigurationProvider.cs:570 (Issue #1566) [https://avatars.githubusercontent.com/u/3947063?s=20&v=4]TimHess left a comment (SteeltoeOSS/Steeltoe#1566)<#1566 (comment)> Thanks for the report @pitermarx<https://github.com/pitermarx>, I agree this behavior is unexpected and undesired... It looks like there were two the related code changes in #1327<#1327>: 1. calling ToMaskedUri on the config server URI<4c3d3e4#diff-73ff43f8c1deaa3b3f5ec28e5863dd19b44a1fd50af19f2e0ffc5a11bc81f243R184-R512> (instead of logging it directly) 2. adding the split on commas<4c3d3e4#diff-cf059d0f13246973fc8e20b1c79ac666cee57201f4eaf18ff54a9d156b7919b3R20> (as you already pointed out) This method is called from several places, and in some cases there could be basic auth credentials included in one or more of the URIs, so we shouldn't remove the splitting entirely and probably need to make it optional — Reply to this email directly, view it on GitHub<#1566 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAXQIUTSU5KYFZYBFKWD3U33NI3YJAVCNFSM6AAAAACDWEYVZKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCOBQGY2DONZWGA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[TimHess]

@bart-vmware initially made those changes; we'll chat about it tomorrow if he doesn't come up with a solution before our scheduled call

[pitermarx]

Thanks for the quick response and for this amazing project!

[bart-vmware]

@pitermarx Does the provided repro config originate from an existing app? Because it seems to me that multiple values for env are not valid. From the Spring docs:

Label can also be provided as a comma-separated list. In that case, the items in the list are tried one by one until one succeeds.

Looking through the Steeltoe tests, I can't find anything that suggests env can be a comma-separated list, in contrast to label and uri. See also how it's documented in Steeltoe, at https://github.com/SteeltoeOSS/Steeltoe/blob/main/src/Configuration/src/ConfigServer/ConfigServerClientOptions.cs#L34.

[pitermarx]

Assuming Env in Steeltoe is the same as profile in Spring

In the spring docs it says
"profile" = ${spring.profiles.active} (actually Environment.getActiveProfiles())
there can be multiple profiles active

also, on the return object ConfigEnvironment
there is a property public IList Profiles { get; } = new List();

this both tells me that it is able to accept multiple profiles i'm actually doing it with spring boot

[pitermarx]

https://cloud.spring.io/spring-cloud-config/multi/multi__quick_start.html

The HTTP service has resources in the following form:

/{application}/{profile}[/{label}]
/{application}-{profile}.yml
/{label}/{application}-{profile}.yml
/{application}-{profile}.properties
/{label}/{application}-{profile}.properties

where application is injected as the spring.config.name in the SpringApplication (what is normally application in a regular Spring Boot app), profile is an active profile (or comma-separated list of properties), and label is an optional git label (defaults to master.)

[bart-vmware]

@pitermarx You're right, multiple profiles are supported by Config Server. I've opened #1567, which URL-encodes the comma in the URL, so it won't crash masking anymore.

[bart-vmware]

The URI splitting needs to stay, because .NET considers the following a valid System.Uri instance:

"http://username:password@www.example.com/,http://user2:pass2@www.other.com/"

And we need to mask all the usernames/passwords in there, not just the first pair.

[bart-vmware]

As a temporary workaround until the fix is released, percent-encode the comma in settings:

"Env": "local%2Cstaging"