As I have finally setup a SSL HTTP server, I’m now running my unit tests against it and I’m faced with an issue of “application goes poof” inside the clients.
Running it inside the debugger, I see that there is an exception raised inside TROSynapseSuperHTTPChannel.CancelRequest but that is trapped by an empty except block
Sadly, when using OpenSSL3 for SSL support, once this exception has occurred, the process is sufficiently damaged that other exceptions occur inside libssl-3.dll and ultimately Windows decides to kill the application.
Now, I already had the case on the server side so I was able to apply a sufficiently similar fix to my own copy.
The only subtlety is that I had to split the timeout wait inside TROSynapseSuperHTTPChannel.DispatchHTTPRequest into a small increment loop or I would end up with an overly long wait when deactivating the channel.
Except that this somehow breaks the non SSL code when dealing with not so large requests.
I had to revert the changes suggested by my patch above as it was causing too many issues, most often deadlocks or “unable to connect” errors because replies were not coming through properly.
How did you manage to apply the idea above without breaking regular non SSL usage like I did?
Are your changes available in a preview version?
Well, after trying various things (thanks for the PM), I came to the conclusion that my change above should be totally reverted, it’s too clumsy and not reliable enough.
However, I was able to come up with a much better solution that is now running just fine here.
It involves changing the way THTTPSend is working so that it no longer does long blocking calls to RecvString but rather short ones until it has received something.
This allows properly aborting the connection and thus returning in a reasonable amount of time, without requiring TROSynapseSuperHTTPChannel to forcefully close the socket.