I observed, among others, quite some timeouts on doing a secure firmware update using HTTPClient (as stated before, actually I do not write directly to a HTTPClient for an update but I use HTTPUpdate of this PR, and HTTPUpdate uses HTTPClient).

I think the root cause of this lies in the fact that, in contrast to the ESP8266 WiFiClient, the ESP32 WiFiClient has a method WiFiClient::setTimeout(uint32_t seconds). This means that when HTTPClient calls _client -> setTimeout() it calls WiFiClient::setTimeout(uint32_t seconds) and not Stream::setTimeout(unsigned long timeout). Also note that the WiFiClient::setTimout() parameter is in seconds while the Stream::setTimeout() parameter is in milliseconds
Also, because of PR #788, the HTTClient::setTimeout() tests for the underlying socket not to be secure (if(connected() && !_secure) …) before calling _client -> setTimeout(). This causing _client -> setTimeout() not to be called on secure connections while actually it should.

The consequences of these errors are:

• On a non secure connection, _client -> setTimeout() is called. This is WiFiClient::setTimeout(). It is called with a milliseconds parameter while the function expects seconds. So a the timeout is a factor 1,000 to high, resulting in effectively no timeout at all
• On a secure connection, _client -> setTimeout() is not called at all

To make things even worse, WiFiClient::setTimeout() does not call Stream::setTimeout(). This means that the timeout for the Stream is the default timeout of 1,000 ms. This again means that Stream::readBytes(), Stream::readBytesUntil(), Stream::readString() and Stream::readStringUntil() will not get the same timeout as HTTPClient(), which is normally much longer (5000 ms, and even longer). This is true for both insecure and secure connections!

The next thing I observe is that PR #934 introduces a test on !_secure in HTTPClient::getStream(). It is perfectly legal to return a secure stream and reading from it, so this check is invalid.

To correct all this, I made the following changes:

• In HTTPClient::setTimeout() and HTTPClient::getStream() remove the test for !_secure
• In HTTPClient::setTimeout() divide and round the millisecond timeout to the nearest second in calling WiFiClient::setTimeout()
• In WiFiClient::setTimeout() call Stream::setTimeout() and multiply the seconds by 1,000 again, because Stream::setTimeout expects milliseconds.

In this way the library functions behavior change is kept to the bare minimum necessary for correcting the errors. Still the consequence of this is that an insecure connection now gets a reasonable timeout while before it had a timeout that was 1,000 times too long (so virtually no timeout at all). Also now a secure connection gets a timeout. Finally, since reasonable timeouts on a HTTPClient are longer that 1,000 ms (the default for the Stream timeout), the Stream::readBytes(), Stream::readBytesUntil(), Stream::readString() and Stream::readStringUntil() now get more time than 1s to complete.

I expect this PR will solve issue #1443.

I expect that the change in this PR will lead to less timeouts and more completed downloads!

@lbernstone @me-no-dev Any chance that these commits will be merged soon?