Consecutive http.get requests

I'm doing two get-requests. As soon as I've gotten an answer from the first one I want to do the second one. So something like this

http.get(url, function (res) {
  res.on('data', function (chunk) { ... });
  res.on('close', function () {
    http.get(url2, function (res) {
      res.on('data', function (chunk) { ... });
      res.on('close', function () {
        console.log('both get-requests completed');
      });
    });
  });
});

However, it doesn't work :( I get this:

ERROR: Socket error -1 while sending
Uncaught Error: CIPSTART failed
 at line 1 col 177
...d 0,Error("CIPSTART failed");}
                               ^
in function "b" called from line 1 col 26
{d=void 0;var f;b&&(f=b(a))?(d=p,b=f):clearTimeout(e);void 0...
                          ^
in function "d" called from line 1 col 325
...c&&(e[c](k),n=!0);n||d&&d(k)}a=a.substr(f+1);"\n"==a[0]&&(a=...
                               ^
in function called from system

I can work around it by wrapping the inner get-call in a setTimeout, but that doesn't feel right. What's the correct way to do this?

You probably need to wait a bit between them - the esp 8266 (that's what you're using, right?) supports up to 5 sockets, but their protocol is ambiguous (or it was - when a socket closed, it didn't tell you which one, or something like that), and espruino doesn't use that functionality yet.

So yeah, setTimeout() is what I'd do, at least in the medium term

Yeah, I'm using an ESP8266 :) I'll post a video in another thread to show off ;)

Which firmware is it on the ESP8266 - 0.25, or the older one?

Probably Espruino 'asks' the socket to close, but then tries to open it again before it has properly closed. I think it's something that should be fixable in the ESP8266 driver pretty easily.

I'm using the newer one, 0.25

@Gordon ... he he he .... Am I sensing the asynchronous story of ESP8266 is biting us again for the partner board story? As you know, a request to do something on the ESP8266 does not mean it is done until the ESP8266 later tells it is :-)

...therefore, a queue is required that holds on to the command and the callback until ESP8266 is ready to do it. This queueing can be a separate - chain linked - module or built into the ESP8266 module. It has also to support some simple querying about the state of the queue and some error handling (callback) on overflow...

Asynch systems were never easy to build... but run very efficient: Espruino is living proof of that.

In this case I think it's easier than having a queue... I literally just wait until OK is received before setting the state of the socket as free. As the ESP8266 can handle 5 clients (iirc?) at the same time, it's just a matter of making sure it uses one of the other 4 :)

If back-to-back requests aren't working then that's a bug IMHO. The esp8266 is definitely capable of doing the back-to-back requests as well a concurrent requests.

...

I think the issue is really just that the JS close callback is called after the socket has been asked to close, but not before we've got the response saying it has. It's not a big thing to work around.

Ok, should be fixed now.

Turns out the socket had already closed, and so the close command created an error, which confused the socket open command.