CPU load during HTTP response can get sockets stuck

Thanks for the example code! I guess if you check E.getErrorFlags() here you'll see an error?

When I finally complete the native AT command firmware this should work a lot better since much more of the AT command handling will be done in interrupts, but as I guess you figured, currently the input data processing is handled in the main thread. There's a roughly 512 byte buffer - but if you stall the main thread for long enough that the buffer gets full, data gets lost.

I imagine that if you pre-calculated the junk variable and sent it, it'd work fine?

There is hardware flow control for the ESP8266 on Espruino WiFi, which I haven't turned on because at the moment there isn't a way to use it in Espruino.

However, you could still use it manually by doing something like:

digitalWrite(A15,0);
var junk = generateJunk(45);
digitalWrite(A15,1);

(I think - I could have got the polarity of A15 wrong).

In your initial code, where you were using the filesystem, did E.getErrorFlags() report any errors when the request got lost? I guess it's possible that just revising that with the raised SD card baud rate would solve your problems, as it could have been the SD card reads that were taking too much time?