Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

https.request() to IPs with octets with leading 0s time out #3148

heyitsbarry opened this Issue Apr 20, 2012 · 7 comments


None yet
6 participants

If sending a GET over https.request() and the host is an IP address with a leading zero in one of the octets, this error event is triggered after the timeout period (2 minutes, for me):

{ [Error: connect ETIMEDOUT] code: 'ETIMEDOUT', errno: 'ETIMEDOUT', syscall: 'connect' }

and no other events are triggered.

An IP like "" will fail, but it will succeed with "" (leading zero removed).

The leading zero address does respond over a terminal cURL request, web browser request, or Ruby Net::HTTP.

This bug was introduced sometime after v0.4, which I understand isn't very descriptive and has not been fixed in either the current stable (v0.6.15) or unstable (v0.7.8) releases.

TooTallNate added a commit to TooTallNate/node that referenced this issue Apr 21, 2012

Can you try this patch? 142e8ca


bnoordhuis commented Apr 21, 2012

Node is parsing the address correctly: 025 is parsed as octal 25, 21 decimal. To wit:

$ python
>>> from socket import gethostbyaddr
>>> gethostbyaddr('')
('google-public-dns-a.google.com', [], [''])
>>> gethostbyaddr('0x8.0x8.0x8.0x8')
('google-public-dns-a.google.com', [], [''])
>>> gethostbyaddr('')
('google-public-dns-a.google.com', [], [''])

A rather useless feature, yes, but it's all according to spec.

Thanks for the info and suggestion- I will try the patch tomorrow and post my results. In the meanwhile, I added a helper to my application which parses any outgoing HTTP request and removes any leading zeros, which fixed the problem.

Sorry for the delay- the patch did not solve the bug. Here is the file I was using to test: https://gist.github.com/2501180

Calling removeLeadingZerosFromIP() on the IP that is set as the host addresses the problem with some simple string manipulation. This gist uses http.request, but the same is true with https.request (which the original bug was using).


Tested with the following script against (v0.10.33 and v0.11.14) succesfully.

var http = require('http');

var options = {
  hostname: '',
  port: 8000,
  path: '/index.html',
  method: 'GET'

var req = http.request(options, function(res) {
  console.log('STATUS: ' + res.statusCode);
  console.log('HEADERS: ' + JSON.stringify(res.headers));
  res.on('data', function (chunk) {
    console.log('BODY: ' + chunk);

req.on('error', function(e) {
  console.log('problem with request: ' + e.message);

// write data to request body

Content was returned as expected. This issue can be closed I think?

@indutny indutny closed this Nov 1, 2014

othiym23 commented Nov 1, 2014

Octal 1 is the same as decimal 1, so I'm not sure that test script proves anything. That said, I also have no evidence that the problem still exists. ;)


indutny commented Nov 1, 2014

@othiym23 and so what? :) it has been 2 years, and I think the best way is just deal with it.

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