Closed Fabian-Gruenbichler closed 5 years ago
Connecting to localhost if HTTP::Daemon object is created without specifying a listenning address is the correct fix. We use that fix in Fedora since 2017-08-06.
If you want to make it working on systems that cannot resolve localhost on both IPv6-only and IPv4-only machines, then the hypercorrect fix would use HTTP::Daemon->url() to obtain an URL WWW::Mechanize should connect to.
By the way this is a duplicate of issue #101.
Since this is a duplicate of #101 I will close this one out and we'll work towards closing the other. They will be linked so that the information in here will still be usable towards resolving that issue.
Debian's libhttp-daemon-perl recently got patched to support IPv6 by switching out the underlying Socket implementation. This has the effect that by default, HTTP::Daemon now listens on/binds to both IPv6 (::) and IPv4 (0.0.0.0) or just one of them, depending on the system's network setup.
Subsequently, WWW::Mechanize test cases started to fail in Debian's CI infrastructure. The failure there is a bit opaque, the actual failing test case is:
with
Patching t/local/LocalServer.pm to revert back to 'localhost' instead of '127.0.0.1', effectively reverting 108cb3526b98c5842790199c1b27d594b11cce72, fixes the issues in Debian, both for hosts that are IPv4 only (with unpatched HTTP::Daemon or just no IPv6 configured), and those that have both IPv4 and IPv6 configured (with patched HTTP::Daemon and IPv6 configured).
IPv6-only hosts remain utterly broken wrt the test cases, since 127.0.0.1 is hard-coded all over the place (not sure whether that is tracked somewhere already).
Since Debian seems to be not affected by the original issue that was fixed by the reverted commit, I am not sure how you want to proceed - but it seemed like something that is worth reporting back upstream in any case ;)