You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the connection is closed by the server, the client outputs an error:
Error: GnuTLS error -110 in gnutls_record_recv: The TLS connection was non-properly terminated.
Server did not properly shut down TLS connection
Error: Could not read from socket: ECONNABORTED - Connection aborted
Error: Disconnected from server
publicfunctionhandleClose()
{
if (!\is_resource($this->stream)) {
return;
}
// Try to cleanly shut down socket and ignore any errors in case other// side already closed. Underlying Stream implementation will take care// of closing stream resource, so we otherwise keep this open here.if ($this->encryptionEnabled) {
@\stream_socket_enable_crypto($this->stream, false);
}
@\stream_socket_shutdown($this->stream, \STREAM_SHUT_RDWR);
}
resolves the issue.
From what I understand, using stream_socket_shutdown() causes the sockets to get closed before the by TLS protocol required "close_notify" message is send. This does not get resolved by a later call to fclose() because the socket is already closed by then.
When the connection is closed by the server, the client outputs an error:
Error: GnuTLS error -110 in gnutls_record_recv: The TLS connection was non-properly terminated.
Server did not properly shut down TLS connection
Error: Could not read from socket: ECONNABORTED - Connection aborted
Error: Disconnected from server
What you're saying may be entirely correct, but we need to double check which "client outputs an error" under what circumstances exactly. I would love to add some tests to confirm correct behavior and avoid future regressions, as we can't randomly change this logic without having some safety nets in place.
Perhaps you can help us by giving some clear instructions how we can reproduce the specific problem you're seeing locally?
What you're saying may be entirely correct, but we need to double check which "client outputs an error" under what circumstances exactly. I would love to add some tests to confirm correct behavior and avoid future regressions, as we can't randomly change this logic without having some safety nets in place.
That is very sound and I would agree with that logic :)
Perhaps you can help us by giving some clear instructions how we can reproduce the specific problem you're seeing locally?
I am tinkering around with a rudimentary implementation of ftps with implicit tls in PHP using reactphp. I ran into this problem when using filezilla as client. At some point, it issues the LIST command which requests data over a second connection. I send this data, and then shut down the data connection as per ftps spec. The shutdown triggers the mentioned error. I was not able to reduce it down to a simple reproduction with eg. server.php and client.php solely using reactphp (the behaviour is not there). It seems to be dependent on the client's connection logic.
Activity
clue commentedon Feb 18, 2025
What problem are you seeing exactly? May I ask you to provide a gist to reproduce this?
Note that this call will be followed immediately by
fclose()in the Stream component.dododedodonl commentedon Feb 18, 2025
When the connection is closed by the server, the client outputs an error:
Replacing
socket/src/Connection.php
Lines 123 to 133 in e04478a
with
resolves the issue.
From what I understand, using
stream_socket_shutdown()causes the sockets to get closed before the by TLS protocol required"close_notify"message is send. This does not get resolved by a later call tofclose()because the socket is already closed by then.clue commentedon Feb 18, 2025
What you're saying may be entirely correct, but we need to double check which "client outputs an error" under what circumstances exactly. I would love to add some tests to confirm correct behavior and avoid future regressions, as we can't randomly change this logic without having some safety nets in place.
Perhaps you can help us by giving some clear instructions how we can reproduce the specific problem you're seeing locally?
dododedodonl commentedon Feb 18, 2025
That is very sound and I would agree with that logic :)
I am tinkering around with a rudimentary implementation of ftps with implicit tls in PHP using reactphp. I ran into this problem when using filezilla as client. At some point, it issues the
LISTcommand which requests data over a second connection. I send this data, and then shut down the data connection as per ftps spec. The shutdown triggers the mentioned error. I was not able to reduce it down to a simple reproduction with eg.server.phpandclient.phpsolely using reactphp (the behaviour is not there). It seems to be dependent on the client's connection logic.