SSLClient::connected "Socket was dropped unexpectedly" because m_client is done but SSLClient still has data in buffer

[JAndrassy]

Describe the bug
SSLClient::connected stops with "Socket was dropped unexpectedly" because m_client is done and returns false for connected() but SSLClient still has unread data in buffer.

To Reproduce
I tested SSLClient library with my networking libraries EthernetENC and WiFiEspAT. Both end with this error in EthernetHTTPS.ino example. EthernetENC reads more data than WiFiEspAT but both stop reading before all data are read.
If I remove if (!client.connected()) { from the example, all data are read.

Expected behavior
It is a valid state that m_client is already closed and doesn't have data so it returns false for connected(). So SSLClient::connected should not stop() and report disconnect while it still has data in buffer. connected() is specified to return true while data are available. https://www.arduino.cc/en/Reference/ClientConnected

Screenshots/Serial Output

Waiting for connection to WiFi
..
Connected to WiFi network.
connecting to www.arduino.cc...
Took: 4103
c_con: 1 br_con: 1 
(it repeats many times)
c_con: 1 br_con: 1
HTTP/1.1 200 OK
Date: Sun, 25 Apr 2021 14:05:03 GMT
Content-Type: text/plain
c_con: 0 br_con: 1
(SSLClient)(SSL_WARN)(connected): Socket was dropped unexpectedly (this can be an alternative to closing the connection)
c_con: 0 br_con: 0

disconnecting.
c_con: 0 br_con: 0
Received 80 bytes in 0.6543, rate = 0.12 kbytes/second

Context:

• Arduino Core Version: Arduino SAMD core 1.8.9
• Relevant Library Versions: WiFiEspAT 1.3.1 and EthernetENC 2.0.1 (GitHub master)
• SSLClient Version 1.6.11

[marcelstoer]

Could someone from the project team confirm this issue? I have the same stack as @JAndrassy and I am seeing the same behavior.

[prototypicalpro]

I haven't had this issue myself but the explanation makes sense. Unfortunately I don't have the bandwidth to try and implement a solution at the moment, but I'd be happy to review any PRs that people submit.

[JAndrassy]

I haven't had this issue myself but the explanation makes sense. Unfortunately I don't have the bandwidth to try and implement a solution at the moment, but I'd be happy to review any PRs that people submit.

just add

if (available())
  return true;

at the beginning of connected

[marcelstoer]

@JAndrassy I generally trust your expertise a lot more than I trust mine wrt to C/C++/Arduino but your proposal doesn't fix the issue for me.

[JAndrassy]

@JAndrassy I generally trust your expertise a lot more than I trust mine wrt to C/C++/Arduino but your proposal doesn't fix the issue for me.

I see. Implementation of available() is wrong too

[Decezaris]

@JAndrassy I generally trust your expertise a lot more than I trust mine wrt to C/C++/Arduino but your proposal doesn't fix the issue for me.

I see. Implementation of available() is wrong too

Same here... why is the available() method wrong?

[Decezaris]

@JAndrassy I generally trust your expertise a lot more than I trust mine wrt to C/C++/Arduino but your proposal doesn't fix the issue for me.

Any workaround about this issue? I tried @JAndrassy's reply but not worked here either

[JAndrassy]

I would remove if (!m_soft_connected(func_name)) return 0;
then maybe the state is right

[Decezaris]

@JAndrassy thanks for the quick reply. I will try that here and report the results

[Decezaris]

@JAndrassy I made both changes, but unfortunately same result :/