I'm trying to debug an implementation of an SMTP server/client using the STARTTLS command and was having problems. I thought maybe I could work out from the example in the README to a working proof of concept, but when I went to run it, the example in the README itself is currently not working using v0.7.5 of IO::Socket::Async::SSL.
The problem seems to be pretty simple and I suspect a bug in IO::Socket::Async::SSL. If I insert the line print "[$crypt-text]"; immediately after the first whenever inside the uc-service subroutine, you can see the problem in the output:
[hello!
][]A react block:
in block <unit> at server.p6 line 5
Died because of the exception:
Cannot write to closed socket
So, the problem appears to be that IO::Socket::Async::SSL is passing through an extra empty string to the tap even though the client has not sent anything.
The obvious workaround for anyone encountering this is to just ignore empty strings received by taps on the secure supply, but it smells like a bug to me.
I'm trying to debug an implementation of an SMTP server/client using the STARTTLS command and was having problems. I thought maybe I could work out from the example in the README to a working proof of concept, but when I went to run it, the example in the README itself is currently not working using v0.7.5 of IO::Socket::Async::SSL.
The problem seems to be pretty simple and I suspect a bug in IO::Socket::Async::SSL. If I insert the line
print "[$crypt-text]";immediately after the firstwheneverinside theuc-servicesubroutine, you can see the problem in the output:So, the problem appears to be that IO::Socket::Async::SSL is passing through an extra empty string to the tap even though the client has not sent anything.
The obvious workaround for anyone encountering this is to just ignore empty strings received by taps on the secure supply, but it smells like a bug to me.