HTTPClient: Split "HTTPC_ERROR_READ_TIMEOUT" up into more detailed error codes

[M-Reimer]

I'm currently facing an issue with some "IoT device web server" which at some point seems to be a bit off with how they implemented the HTTP standard. After some runtime in some situation I end up getting "HTTPC_ERROR_READ_TIMEOUT" all the time. Sometimes this "revives" somehow just to reappear later.

The problem is that this error code could actually mean different things. Several checks return this code. We have it at the following locations in the GIT revision I've checked (with GIT revision in URLs to make them "stable"):

1. Arduino/libraries/ESP8266HTTPClient/src/ESP8266HTTPClient.cpp

   Line 35 in 140d0ff

   case Stream::Report::TimedOut: return HTTPC_ERROR_READ_TIMEOUT;

2. Arduino/libraries/ESP8266HTTPClient/src/ESP8266HTTPClient.cpp

   Line 673 in 140d0ff

   return returnError(HTTPC_ERROR_READ_TIMEOUT);

3. Arduino/libraries/ESP8266HTTPClient/src/ESP8266HTTPClient.cpp

   Line 709 in 140d0ff

   return returnError(HTTPC_ERROR_READ_TIMEOUT);

4. Arduino/libraries/ESP8266HTTPClient/src/ESP8266HTTPClient.cpp

   Line 1075 in 140d0ff

   return HTTPC_ERROR_READ_TIMEOUT;

Where only the last one actually is based on actual measurement of time. The first one may also be timeout related (didn't dig that deep). Point 2 and 3 can also be "malformed data" which would be interesting to know so I can check what my server does wrong here. Probably it would be even possible to make the HTTPClient more robust once I know what is wrong on the server side. The access works every time with a "regular browser" so I guess the HTTP implementation is more forgiving there.

[joysfera]

FWIW, after upgrading from v2.7.4 Arduino core to v3.0.2 on my ESP8266 WebServer my ESP8266 HTTPClients started getting this very HTTPC_ERROR_READ_TIMEOUT" after some runtime (hours). Sometimes this revives for a moment but then falls back to error -11 (timeout). The access to the webserver works every time with a "regular browser" (just like for you).

I emphasize that this used to work fine for years when the server was built with pre-v3.x Arduino cores so it seems to be related to the server side but I can't figure out what exactly is wrong and where.
Restoring v2.7.x webserver fixes the issue. Clients might be v2.7.x based or v3.0.2, both seem to work OK.
Very hard to debug as I haven't been able to reproduce it in my lab, it only happens far away in the field.

[d-a-v]

If you have any idea on how to reproduce your issues, that will help.

[joysfera]

Seems like the key is to have at least three or four "simultaneous" clients (I've got four clients - each fetching data from the server every five seconds). Sometimes it takes several hours to reproduce, sometimes it happens almost instantly - probably when two or more of the clients' requests clash? I don't know, just guessing.

FYI, I described my problem in detail here: https://www.esp8266.com/viewtopic.php?f=32&t=23296

I haven't created my own github issue because I don't have a short code to reproduce it. I just noticed that this github issue describes what I get (HTTP TIMEOUT) so I thought I'd mention my story - perhaps with more detailed error reporting from HTTPClient I'd guess more quickly what's up with the WebServer? Or maybe not.

[ozzcet]

Actually , I have similar issue. I have build kind of push button that connect to server through out http protocol. Sometime I have gotten -11 some time get 200 who knows why ? Weird... This caused push button more than one time to get 200...

[kirurui]

I 2 it...

[d-a-v]

There was a recent related update, currently in master branch: see #8216
Not saying this will solve this bug, but worth giving a try.
Can you give a try with master branch ? (Arduino users can try the snapshot release v0.0.1).

[d-a-v]

I am currently running PostServer and PostClient.

On client, delay between requests is removed, and an error counter is added and increased when retcode is not 200.

Setup:

• Server on esp8266
• one client on another esp8266
• another client on host:

cd test/hosts
make list
make D=1 ../../libraries/ESP8266HTTPClient/examples/PostHttpClient/PostHttpClient

I'll tell you just before I die burning in the 2.4G flow, or if a counter happens to be greater than 0.
If any of you has a publishable app to test, the issue will be narrowed faster.
You also may enable core and library debug messages so there is more to show.

[joysfera]

Isn't the PostClient re-using existing connection? That could mask what I experienced with HTTP 1.0.
Also, I'd insert a delay(500) to the PostServer's loop() to simulate that the server node has also some other work to do.

I'll arrange a similar test with 3+ clients when I get some spare time. I just invested half a day to return to core v2.7.4 and surprise surprise - SPIFFS.check() was causing a fatal crash and a boot loop there. Took me several hours to debug it.

[d-a-v]

I have updated my test to use HTTP1.0.
I have now 3 host clients, 1 esp http1.0 client and 1 esp server with 500ms loop.
I'll let it run for some hours. Then if I still have no error, I'll remove the 500ms.

[joysfera]

Do you use the v3.0.2 release or master branch? Just asking if it got fixed in the master by any chance.
BTW, we kinda hijacked @M-Reimer issue, that's not fair. Though I am very very glad you @d-a-v pay so much attention to my issue, thank you!

[joysfera]

@d-a-v one more note: my server application also keeps a MQTT connection alive (probably consuming at least one network socket all the time) and does a HTTP POST to another server every minute (which requires another socket). That limited amount of sockets might help to cause the issue. On the plus side my clients are not hammering the ESP8266 server that often - only once in 5 seconds.