Now that it's working but with an unwilling timeout, you can updatewritetostreamdatablock() for it to stop when it can no longer read from the_client.
This is an old fashion function. A that time there were usually several attempts to read or write before giving up. Today one attempt and timeout checking is enough. This is addressed by#6979.
In the meantime, what is missing there is checking peer connectivity. That is answering to that question:
Is it possible to get more incoming data ? One just need to check_client's::available()==0and (::connected()==false or::status() != WL_CONNECTED). When this is true, it is no longer useful to wait for the timeout, peer has closed the connection and everything that is to be read is already swallowed.

With apologies, I'm not seeing how this would help, at least in the current implementations ofHTTPClient andStream. My reading is that, in a no Content-Length scenario (solen = -1), oncereadBytes() is called, the timeout controls, regardless of anything else. If that's correct, checking peer or wifi connectivity withinwriteToStreamDataBlock would not be useful. Changes to address this would need to occur within Stream, and thenwriteToStreamDataBlock would need to be modified to check the parameters you mention. In addition, I would still think a timeout would be needed (and it would have to be added towriteToStreamDataBlock as well) in the case where you remain connected but the server just decides to take a nap.

Perhaps the word 'meantime' threw me and you are asking for theHTTPClient mods prospectively to work with the changes to Stream implemented in#6979?

In#6979,writetostreamdatablockis removed and replaced byStream::to() - having both timeout and end of stream detection - but still lacks from maintainers's review because it was introducingStream:: inheritance toString::, now removed, that was considered by some as a blaspheme, which I still don't understand why ;) Maybe I should repost it with another name and its history expunged of the heresy.

But before#6979 is considered, a fix is needed for your issue, and#7692 too which is the same issue.

End of TCP connection cannot currently be handled byStream:: so it has to bewritetostreamdatablock()'s job. While examining#7692 I ended up with the following and stopped there because I was too optimistic regarding#6979 consideration. You may try it. The logic is the following: do not ask too much toStream::readBytes() because that one will wait until timeout that all requested data are received. Instead ask for what's already there and keep retrying until all data are received.

+++ b/libraries/ESP8266HTTPClient/src/ESP8266HTTPClient.cpp@@ -725,7 +725,7 @@ int HTTPClient::writeToStream(Stream * stream)     int ret = 0;      if(_transferEncoding == HTTPC_TE_IDENTITY) {-        if(len > 0) {+        if(len > 0 || len == -1) {             ret = writeToStreamDataBlock(stream, len);              // have we an error?@@ -1184,6 +1184,9 @@ int HTTPClient::writeToStreamDataBlock(Stream * stream, int size)         if(readBytes > buff_size) {             readBytes = buff_size;         }+        int av = _client->available();+        if (readBytes < 0 || readBytes > av)+            readBytes = av;          // read data

If this works for you, please update your PR.

That worked nicely. And now I understand what you meant about effectively checking_client's::available()==0 and::connected()==false. The idea about reading what's already there was what I was trying to do -- poorly, as I didn't include the 'until all data are received' part -- in my initial PR. With your help, I think we've now got it right. Thanks again.