HTTP Timeouts in Node

I needed to update some code at work the other day to add a timeout to an HTTP GET request.  Simple enough, I thought.  How hard could it be?

Looking back, it is pretty straight forward, and the code makes perfect sense, but definitely wasn’t intuitive when first trying to get it working.  I’m writing this mainly as a note to myself about the proper way to handle this in the future.

The Starting Point

The code I was updating called a GET endpoint on localhost.

var req = http.get(url, res => {

    //handle success

}).on('error', e => {

    //handle error

});

Adding a Timeout

I hadn't added a timeout to a request in Node before, using the built-in HTTP library, so I did what any red-blooded developer would do, and copy-pasted from elsewhere in the code that was doing something similar.

    var req = http.get(url, res => {

        //handle success

    }).on('error', e => {

        //handle error

    }).on('socket', sock => {

        sock.setTimeout(500);

        sock.on('timeout', () => {

            req.abort();

        });

    });

This seemed oddly confusing for something so simple, but worked fine.  Reading the docs, I could see that the 'socket' event fires when a socket is assigned to the request.  We then set a timeout directly on the socket, and abort the request once that occurs.

I thought the abort wasn't necessary, since the request had already timed out, so I removed it and it still worked.  The timeout event would fire right away, instead of waiting the default 2 minutes, like it used to, to error out.  I was actually missing something important, but hadn't noticed it yet.

HTTPS

Next, I had to update http to https, which normally just means adding a single letter to your require statement.  Since this was localhost though, and didn't have a certificate, I also needed to ignore certificate errors.  Again, I used my normal trick of finding another call that did this, and copying from it.

I found a POST call to a different localhost endpoint, and saw that it was using https.request (instead of https.get) and that it was using an options object, instead of passing the URL as a string.  The options object had a 'rejectUnauthorized' property, which is what I needed to ignore certificate errors.  Why they used the term 'Unauthorized', instead of 'InvalidCert' or something similar, is beyond me.

I figured that request() just always used an option object, instead of a URL like get() did, and to get access to the 'rejectUnauthorized' property, I would need to need to switch to it.  So, I changed my http.get to https.request, passed it an option object, breaking out the host, path, port and method, and passed that in, instead of the URL string.

let options = {

    host: 'localhost',

    path: '/resource',

    port: '12345',

    method: 'GET',

    rejectUnauthorized: false

};

var req = http.request(options, res => {

    //handle success

}).on('error', e => {

    //handle error

}).on('socket', sock => {

    sock.setTimeout(500);

    sock.on('timeout', () => { });

});

Simple enough, but it didn't work.  The call would hang.  It took some digging, but it turns out I missed an important line from the request() example I copied from.  I knew that the get() method I was using before would automatically set the method to GET, but apparently it also calls end() on the request, which I didn't realize was needed.  It makes sense, as the way request are modified by method chaining means you wouldn't know when you were done updating the request, but it wasn't obvious at first.

After I got that figured that out, I then realized that both get() and request() can take either a url or options object, so I actually didn't need to use request(), and switched back to get() (and removed the call to end() I had just added).  Everything was working now, until I pushed the code to an environment where the logging code actually wrote to somewhere.

Aborting

It turns out that whenever my request timed out, I was still logging an error, but only after 2 minutes.  Again, I dug through the docs and found that when a request times out, it doesn't actually end.  It would keep going until it was forcefully timed-out and killed, after the default 2-minute timeout.  In the timeout event, you still need to manually abort the request, which the original code I copied from did.  Yet another example of it never being a good idea to remove code you don't understand, until you understand it.

That change still didn't get everything working though.  The code would still throw an error ("socket hang up"), but it would do it immediately after the timeout, instead of after 2 minutes.  The final piece was realizing that aborting a request still throws an error, but sets the 'code' property of the error object to 'ECONNRESET'.  So when I checked for that in the error handler, I could successfully ignore timeouts, and handle regular errors.  Annoyingly though, error.code is also set to 'ECONNRESET' if the server resets the connection, so to be truly accurate, you would need to set a variable in the 'timeout' event that the 'error' event could check.  For my needs though, that wasn't necessary, and I just checked error.code.

Wrapping Up

In the end, I got the code working, and everything makes sense now.  While I understand the logic behind most design decisions of the API (the name of 'rejectUnauthorized' not withstanding), I feel like many parts aren't very intuitive, especially for those coming from a different background, such as .NET.

After finding out about request.setTimeout, which mimicks the more verbose socket code, the final code is below:

let options = {

    host: 'localhost',

    path: '/resource',

    port: '12345',

    method: 'GET',

    rejectUnauthorized: false

};

var req = https.get(options, res => {

    //handle success

}).on('error', function(err) {

    //ignore timeouts

    if (err.code === "ECONNRESET") {

        return;

    }

    //handle error

}

).setTimeout(25, () => {

    req.abort();

});