TROSynapseSuperHTTPChannel closes connection while read is in progress


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.

Here is a suggested patch with my changes: (1.4 KB)

Note that with this change applied, I strongly suspect that the empty except block will no longer be needed which is a bonus point anyway.

Hope this helps.


thx for code.
unfortunately we can’t apply this patch as is because Delphi 7 knows nothing about TMonitor

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?


check PM

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.

Here is a patch with those changes: (1.5 KB)

I know this modifies a file from a third party library which you might be reluctant to do in your own copy as it complexifies later updates.

I have submitted my changes to the library owner here

Sorry for all the back and forth on this issue and the time you wasted on my initial suggestion.


lets wait for a bit.
probably they will apply your patch soon so we’ll merge your changes to Remoting SDK.