"Connection Refused" and "Operation Timed Out" missing in response

[tetherit]

From the command line:

$ curl 127.0.0.1:1234
curl: (7) Failed to connect to 127.0.0.1 port 1234: Connection refused
$ curl 192.168.123.123:1234
curl: (7) Failed to connect to 192.168.123.123 port 1234: Operation timed out

But in typhoeus:

>>> response = Typhoeus.get("127.0.0.1:1234")
return_code=>:couldnt_connect
return_message=>"Couldn't connect to server"
>>> response = Typhoeus.get("192.168.123.123:1234")
return_code=>:couldnt_connect
return_message=>"Couldn't connect to server"

It seems Typhoeus does not give a reason for why it failed to connect and it is impossible to distinguish a connection refused from a connection timed out. On the other hand curl, wget, telnet, etc, etc and several ruby HTTP libraries I tried all give you a reason, a couple of examples:

$ telnet 127.0.0.1 1234
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
telnet: Unable to connect to remote host
$ telnet 192.168.123.123 1234
Trying 192.168.123.123...
telnet: connect to address 192.168.123.123: Operation timed out
telnet: Unable to connect to remote host

$ wget 127.0.0.1:1234
--2015-03-16 18:51:09--  http://127.0.0.1:1234/
Connecting to 127.0.0.1:1234... failed: Connection refused.
$ wget 192.168.123.123
--2015-03-16 19:02:16--  http://192.168.123.123/
Connecting to 192.168.123.123:80... failed: Operation timed out.

I think this is quite a serious omission in typhoeus that needs to be addressed (even if outside of libcurl). Because except for this issue, this library is perfect for my use.

It was a serious enough issue for the curl CLI to address it too it seems.

[hanshasselberg]

There is also return_message which is like a description.

[tetherit]

Doesn't help either, similar "couldn't connect" message without saying the connection was refused :(

[4] pry(main)> response.return_message
=> "Couldn't connect to server"

[hanshasselberg]

Thats all I know. Btw what is the difference?

[tetherit]

"Connection Refused" means there is nothing listening on the port and the server has refused the connection, "Couldn't connect" could mean anything - maybe the server is not pinging at all, maybe the server is silently dropping the request, maybe the web server is responding too slowly, etc - so if there is an intermittent issue it would be difficult to figure out what is going on from the logs.

[hanshasselberg]

Thanks for the explanation although I still don't understand how all these things are different from a client perspective.
On the libcurl error page it also mentions Error 7 (which is the number from your curl output):

CURLE_COULDNT_CONNECT (7): Failed to connect() to host or proxy.

Which indicates that it is the same after all.

[tetherit]

I'm looking for an HTTP library to use to communicate between RESTful services. When something goes wrong - as it often does with my code, heh - it helps to know what it was by looking at the logs and "couldn't_connect" is not very helpful/useful :(

Even an exception like Errno::ECONNREFUSED would be more helpful than a generic error which doesn't say very much.

[hanshasselberg]

It sounds like Typhoeus might not be what you are looking for.

[hanshasselberg]

Typhoeus doesn't raise exceptions like these on purpose btw.

[tetherit]

I prefer not to have exceptions too, but I need some kind of information as to why the request failed :(

[hanshasselberg]

There are plenty in Typhoeus - more in any other client I know. I think your example is impossible to tell apart for clients. Even your example

$ curl 127.0.0.1:1234
curl: (7) Failed to connect to 127.0.0.1 port 1234: Connection refused

is basically saying the same like Typhoeus. Which is not surprising since they are using the fundamentals: libcurl.

[tetherit]

It isn't, it's saying "Connection refused" - that is the bit I am after but I cannot get it in typhoeus - "Connection refused" is very descriptive, it says the operating system refused the connection to the port.

"couldnt_connect" says nothing. Why couldn't it connect?

[hanshasselberg]

Yes it is not saying the same. But the error number points to the same underlying problem: couldnt_connect.
I think you are mistaken and this is the same error you get in Typhoeus. I also think it is impossible to tell if the connection was refused or if it wasn't able to connect.

[Zapotek]

@Hackeron Have a look at: http://curl.haxx.se/libcurl/c/libcurl-errors.html

There's no "connection refused" error code for these cases, just CURLE_COULDNT_CONNECT.
The CLI curl client probably provides that message when that error code is encountered, as it's probably making the assumption the only reason for that error would be a refused connection. Otherwise it would have been CURLE_COULDNT_RESOLVE_HOST or some other code.

Typhoeus simply forwards the information libcurl is giving it and from a programmatic perspective that's what it should be doing.

The discrepancy between the libcurl codes and the curl CLI client's message is interesting though, but that's not an issue with Typhoeus.

[tetherit]

Not true, it is not making an assumption. For example, even when a connection times out in Typhoeus, it still does not return the reason for why it could not connect:

>>> response = Typhoeus.get("192.168.123.123:1234")
:return_code=>:couldnt_connect
>>> response.return_message
=> "Couldn't connect to server"

On the other hand curl, wget, telnet, etc, etc and several ruby HTTP libraries I tried all give you a reason, some examples:

$ curl 127.0.0.1:1234 
curl: (7) Failed to connect to 127.0.0.1 port 1234: Connection refused
$ curl 192.168.123.123:1234
curl: (7) Failed to connect to 192.168.123.123 port 1234: Operation timed out

$ telnet 127.0.0.1 1234
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
telnet: Unable to connect to remote host
$ telnet 192.168.123.123 1234
Trying 192.168.123.123...
telnet: connect to address 192.168.123.123: Operation timed out
telnet: Unable to connect to remote host

$ wget 127.0.0.1:1234
--2015-03-16 18:51:09--  http://127.0.0.1:1234/
Connecting to 127.0.0.1:1234... failed: Connection refused.
$ wget 192.168.123.123
--2015-03-16 19:02:16--  http://192.168.123.123/
Connecting to 192.168.123.123:80... failed: Operation timed out.

I think this is quite a serious omission in typhoeus that needs to be addressed (even if outside of libcurl). Because except for this issue, this library is perfect for my use.

It was a serious enough issue for the curl CLI to address it too.

[Zapotek]

You are correct on that front, sometimes it returns operation_timedout and others couldnt_connect, but @i0rek is better suited to answer why that is.

I do believe that this issue is separate from your original one as there doesn't seem to be an error code for a refused connection in libcurl in the first place.

I'd also quite like to know about the inconsistent return codes for timed out operations though.

[tetherit]

Thank you :) - I edited the title and description to better reflect the issue I am seeing - I am actually not seeing operation_timeout at all, it's returning couldnt_connect for tcp connection timeouts.

[Zapotek]

I remember it doing that and there's code in my system to account for that behavior (checks for both operation_timedout and couldnt_connect to identify time-outs) so I guess there must have been a reason.

There are multiple phases during each request that can time-out so I guess it depends on when it happens. There may be a DNS resolution timeout, a connection timeout, an HTTP response time out or the combination of all those operations violating the given timeout.