Here is another test approach:
First I send it a completely fine AT+CIPSEND=0, and while it is busy sending i just send it a "ms:[]" text string to see what it responds while busy.
...
Recv 79 bytes
ms:[36]
busy s...
ms:[60]
busy s...
ms:[94]
busy s...
ms:[128]
busy s...
ms:[153]
busy s...
ms:[188]
busy s...
ms:[223]
busy s...
SEND OK
ms:[248]
ERROR
...
It looks like the "SEND OK" is the condition to accept new messages and there is no hidden internal state where it "might" be ready to receive more commands - before that event. After SEND OK it is no longer busy - now my test command is treated as a command and generates an appropriate error.
Now. With the exact same http request having HTTP response data returned really fast from the server:
...
Recv 79 bytes
ms:[24]
busy s...
SEND OK
+IPD,0,183:HTTP/1.1 204 No Content
Content-Type: text/plain; charset=utf-8
Date: Tue, 14 Nov 2017 09:40:59 GMT
Server: X54JetStream
Connection: Keep-Alive:
Keep-Alive: timeout=15, max=1000
ms:[60]
ERROR
...
After 60 ms we got BOTH the SEND OK and the entire HTTP response back. And following the same logic. Before sending my false timestamp strings will be rejected with "busy" but after SEND OK the ESP8266 also have an opinion on the quality of the false commands and you get an ERROR.
How come "SEND OK" is in any way related with what data comes back. The actual data sent by the device in the HTTP request is already at the remote server, have ben parsed as valid HTTP and response is sent back in a few ms. Why does it not signal "SEND OK".
What have I missed here?