fixed http.end taking too long

[yigitabi5444]

http end takes 20-30 seconds if there is a large amount of data
replacing this read loop with flush fixes that problem

[CLAassistant]

All committers have signed the CLA.

[mrengineer7777]

Discussion: Does flushing the buffer rather than reading it mean the final bytes aren't processed? Does the current read() perform any processing? I see read() is part of WiFiClient.cpp, and followed it to WiFiClientRxBuffer->read(). I don't see any processing events, but I can't be certain from a quick glance at the code.

[yigitabi5444]

Im not sure if read does any processing but the same fix was implemented over here: #828

[mrengineer7777]

@yigitabi5444 So you are making the HTTPClient.disconnect() behavior consistent with HTTPClient.end().
BTW, the change for end() is here: e3a5ae4

Seems reasonable. I reviewed the commit history for HTTPClient.cpp and see no regressions for end() or disconnect() since 2018. This PR seems like a good fix. Just not sure if read() does any processing. Hopefully Espressif employees can clarify.

[me-no-dev]

thanks @yigitabi5444

[lemonkey]

WARNING: changing from looping while available() > 0 and reading the bytes on the client one at a time to calling flush() can run into issues when available() returns a value > 0 but the socket is no longer connected. WiFiClient::flush( ) currently gets stuck in a loop and never returns for this scenario.

This also impacts HTTPClient.disconnect() which was similarly updated recently.