Skip to content

Encode instance ids in RestClient getInstance requests - #4614

Merged
ryanjbaxter merged 1 commit into
spring-cloud:5.0.xfrom
kdelay:fix/restclient-instance-path-encoding
Oct 7, 2026
Merged

ryanjbaxter merged 1 commit into
spring-cloud:5.0.xfrom
kdelay:fix/restclient-instance-path-encoding

Conversation

@kdelay

@kdelay kdelay commented Oct 6, 2026

Copy link
Copy Markdown
Contributor

RestClientEurekaHttpClient.getInstance concatenates the instance id into the path, so it is parsed as a URI template and an id containing # or ? is cut at that character. #4291 fixed this for the RestTemplate and WebClient transports (gh-4121), but the RestClient transport, now the default in 5.0, still builds the path as a string.

This uses pathSegment, as WebClientEurekaHttpClient does.

testGetInstance already passed test#1.[3.?]! but never checked what the server received. The mock now returns the requested id and the test asserts it. Without the fix:

expected: "test#1.[3.?]!"
 but was: "test"

./mvnw -pl spring-cloud-netflix-eureka-client -am verify passes.

RestClientEurekaHttpClient built the getInstance URLs by string
concatenation, so an instance id containing '#' or '?' was cut at that
character and the request asked for a different instance. Build the path
with pathSegment, as the WebClient transport already does.

The shared test passed such an id but never checked what the server
received; the mock now echoes the requested id back.

Signed-off-by: kdelay <kdelay20@gmail.com>
@ryanjbaxter
ryanjbaxter merged commit 3f7ab5b into spring-cloud:5.0.x Oct 7, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants