HTTPClientSession fails with "Connection Refused" on localhost

[werasmus]

Expected behavior

• I have code that uses a HTTPClientSession to communicate to a webserver via localhost on windows.
• When I disable my network, I expect the sending of client requests to still resolve, as I'm communicating on localhost. As an example, chrome can IE can still connect to the endpoint, as well as our java client.

Actual behavior

• The "sendRequest" call fails with "Connection Refused". This even happens when I create a new client session every time.

Steps to reproduce the problem (from https://ideone.com/CE0R6j)

#include <Poco/Net/HTTPSessionInstantiator.h>
#include <Poco/Net/HTTPRequest.h>
#include <Poco/Net/HTTPClientSession.h>
#include <Poco/Net/HTTPSessionFactory.h>
#include <iostream>
#include <memory>
#include <string>
#include <cstdlib>

using namespace Poco::Net;

namespace {
struct SessionInstantiatorRegistrar
{
    SessionInstantiatorRegistrar()
    {
        HTTPSessionInstantiator::registerInstantiator();
    }
    ~SessionInstantiatorRegistrar()
    {
        HTTPSessionInstantiator::unregisterInstantiator();
    }
};
}//anonymous

int main()
{
    try {
        SessionInstantiatorRegistrar scopedRegistrar;
        //NOTE: Pick any valid endpoint... This is ours...
        HTTPRequest statusRequest(HTTPRequest::HTTP_GET, "/api/v1/tray", HTTPMessage::HTTP_1_1);
        Poco::URI uri("http://localhost:28488");
        std::unique_ptr<HTTPClientSession> clientSession(HTTPSessionFactory::defaultFactory().createClientSession(uri));
        auto& requestStream = clientSession->sendRequest(statusRequest);
        std::cout << "Request successfully sent" << std::endl;
    } catch(const Poco::Exception& ex) {
        std::cerr << ex.displayText() << std::endl;
        return EXIT_FAILURE;
    }
    return EXIT_SUCCESS;
}

POCO version

Poco 1.7.8: "Host not found"
Poco 1.9.0 "Connection Refused"

Compiler and version

Visual Studio 2017

Operating system and version

< Windows 10

Other relevant information

Using 127.0.0.1

• inet_addr resolves this normally as IPV4 - No Problem

Using localhost

• In_addr fails to resolve to IPV4
• Attempts to resolve as IPV6 by calling getaddrinfo with AI_NUMERICHOST (which shouldn’t work, as localhost is not numeric
• IpAddress::tryParse therefore fails
• Poco then try to resolve address by calling hostByName from SocketAddress, but by default hintFlag contains option DNS_HINT_AI_ADDRCONFIG. This will never work, as from windows documentation “The IPv6 and IPv4 loopback address is not considered a valid global address.”.
• It seems clear that Poco has made this choice deliberately, however that makes it impossible to use a valid loopback hostname.
• Removing DNS_HINT_AI_ADDRCONFIG from the hint will resolve localhost using getaddrinfo (in our case to IPV6 address first, and IPV4 second - Refer HostEntry constructor in HostEntry.cpp). HostEntry now contains two addresses, the first being IPV6 format
• In SocketAddress.cpp, init is then only called with the first address (IPv6)
• connect (further down) is also only called with one IP address (IPv6) and fails with 10061

This SO article might be relevant

[zosrothko]

Could you try to use the ip address with quad number: 127.0.0.1 instead of localhost...

[werasmus]

Hi. We've noticed that ipv dotted decimal works due to localhost address translation that goes wrong. Will look into it on Monday. Behavior of 1.90 better than 1.78. I will modify the issue. Error changed in 1.90

…

On 17 Mar 2018 14:07, "zosrothko" ***@***.***> wrote: Could you try to use the ip address with quad number: 127.0.0.1 instead of localhost... — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2226 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIC6kKTMAxEygmw3NZOMfMTKT1-7--u_ks5tfPxkgaJpZM4StwEG> .

[zosrothko]

"localhost" is resolving in a IPV6 address, that's why the dotted ip address works

[budric]

I ran into this issue with version 1.8.1. I have a server and it was only listening on IPv4 address. The DNS for FQDN of the server returns 2 entries, IPv6 followed by IPv4. Poco's HTTPClientSession seems to try only the first address which happens to be IPv6, throws connection refused error (which is true) and that's it.

I have not run into the same problem with other clients like curl/chrome/firefox/ie - either by chance (maybe host lookup in those cases always gets IPv4 address first) or intentionally going through through every address, these clients always reach the server.

My question is, is this considered a bug in Poco? Should Poco HTTPClientSession try all addresses returned by DNS before declaring connection refused?

[werasmus]

Should it try all addresses? In my opinion, yes. We've managed to find a workaround without change to the library. I might post it tomorrow. Can't remember the exact details now. I can recall the ipv6 being selected and rejected though.

…

On Wed, 04 Apr 2018, 23:56 budric ***@***.***> wrote: I ran into this issue with version 1.8.1. I have a server and it was only listening on IPv4 address. The DNS for FQDN of the server returns 2 entries, IPv6 followed by IPv4. Poco's HTTPClientSession seems to try only the first address which happens to be IPv6, throws connection refused error (which is true) and that's it. I have not run into the same problem with other clients like curl/chrome/firefox/ie - either by chance (maybe host lookup in those cases always gets IPv4 address first) or intentionally going through through every address, these clients always reach the server. My question is, is this considered a bug in Poco? Should Poco HTTPClientSession try all addresses returned by DNS before declaring connection refused? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2226 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIC6kD0DCrn_z0XDkIweCrt8rsx4zfF9ks5tlUF-gaJpZM4StwEG> .

[zosrothko]

The is a know problem. One solution could be to use a global variable stating which should go in first in the DNS list, either IPV4 or IPV6, defaulted to IPV6. See #1871

[Bittuw]

Is there a correct solution of this problem?

[RaBa64]

In /etc/hosts, I changed the line
::1 localhost ip6-localhost ip6-loopback
to
::1 ip6-localhost ip6-loopback
Now it works.

[github-actions]

This issue is stale because it has been open for 365 days with no activity.