Skip to content

Conversation

@rschmitt
Copy link
Contributor

Binding to 0.0.0.0 is not guaranteed to result in a socket that is reachable via the loopback address, even when requesting an ephemeral port assignment by binding to port 0. It is possible for another process on the system to bind to the loopback address at that same port, and then client requests will go to that process instead of the test server, resulting in occasional cryptic test failures.

By instead binding to the loopback address specifically, rather than the wildcard address, we can prevent binding to a port that is already in use. This significantly improves the reliability of the test suite.

Binding to 0.0.0.0 is not guaranteed to result in a socket that is
reachable via the loopback address, even when requesting an ephemeral
port assignment by binding to port 0. It is possible for another process
on the system to bind to the loopback address at that same port, and
then client requests will go to that process instead of the test server,
resulting in occasional cryptic test failures.

By instead binding to the loopback address specifically, rather than the
wildcard address, we can prevent binding to a port that is already in
use. This significantly improves the reliability of the test suite.
@rschmitt rschmitt merged commit bdd4c16 into apache:master Dec 18, 2025
10 checks passed
@rschmitt rschmitt deleted the loopback branch December 18, 2025 16:51
@ok2c
Copy link
Member

ok2c commented Dec 18, 2025

@rschmitt Could you cherry-pick it to 5.4.x?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants