OctoPrintAPI
OctoPrintAPI copied to clipboard
chunkysteveo
Infinite loop (or almost) with OctoprintApi::sendRequestToOctoprint()
Hello, The the method OctoprintApi::sendRequestToOctoprint() seems, with some occasion, loop for ever or almost.
One of the occasion is with this answer (octoprint is down and Nginx is responding) :
HTTP/1.0 502 Bad Gateway
Cache-Control: no-cache
Connection: close
Content-Type: text/html
<html><body><h1>502 Bad Gateway</h1>
The server returned an invalid or incomplete response.
</body></html>
The code is waiting for a "Content-Length" that never happen.
What do you think about using ArduinoHttpClient instead of a custom code ? https://github.com/arduino-libraries/ArduinoHttpClient
I could take a look at the code to see if we can catch this event. The custom code was to allow for any network client (esp8266, esp32, ethernet etc) to connect without dependencies.
We could utilise the return code (502) if not 200, and break out the loop? Will take a look on a break - but good spot - you're really pushing the library to some good edge cases! :)
steve
I’m not sure this is the only event with such problem . And it’s not easy to test all cases: direct request to octoprint, Nginx, Apache, Haproxy, etc. It could depend on the configuration.
Custom codes for generic function, like http request, tend to be more buggy, as they are not tested as well as a standard library. That’s why, high level library focused should rely on mid level ones.
A way to keep the compatibility with Arduino and ESPxxxx is to use directives:
#if defined(ARDUINO)
// Arduino specific code
#elif defined(ESP8266)
// ESP8266 specific code
#else
#Error “Platerform not supported”
#endif
I’m haven’t the exact code, it’s just for the idea. I have no more ESPxxxx board at home, I can only test with an MKR 1010.
After 4 days of test, I have no more infinite loops.
The problem was with empty responses like 502 and, also, with the Wifi driver.
On the MKR 1010, perhaps with other boards, if WifiClient::available() is called too often, the driver receives errors from the ESP and can't deal with it. That's why there is delay(100) while waiting.
you've been busy again! Let me check out the updates and have a play with my ESP boards.
Steve