SSL.File->read() will throw an exception if the connection is closed at the time of the call, regardless of whether there¢s data to be read. That¢s certainly a divergence from Stdio.Fd->read().
It's also completely useless. That way you will never be able to get data the server sends just before it closes the connection. I'd say the testsuite did a good job of finding a serious bug here.
On Dec 3, 2020, at 12:08 PM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum 10353@lyskom.lysator.liu.se wrote:
SSL.File->read() will throw an exception if the connection is closed at the time of the call, regardless of whether there¢s data to be read. That¢s certainly a divergence from Stdio.Fd->read().
It's also completely useless. That way you will never be able to get data the server sends just before it closes the connection. I'd say the testsuite did a good job of finding a serious bug here.
I think in practice the divergence hasn’t surfaced because most read loops are fairly tight and the closing of the connection involves a round trip with the peer (or they’re using callback mode).
I feel like that’s giving too much credit to the test… ;)
I think the test was naive in it’s assumption that the file should still be open by the time it checked. It certainly was written to test behavior at odds with its documented behavior (that it should work like Stdio.File->read()). Ok, I guess we wouldn’t have had this conversation if the test hadn’t failed.
I will look at removing the exception on read().
pike-devel@lists.lysator.liu.se