HTTP Request / WEB SERVICE CALL: freeze with https url

4D v16 & v17 (up to b233645) Server and/or client, MS Windows
Using the 4D commands HTTP Request (and possibly WEB SERVICE CALL) to make requests to a remote system, using an https urs, at times results in repeated application freeze.

I have 9 individual databases that hit a particular outside technology, via an HTTP Request command, using an https:// url, all began freezing. Even after a restart: as soon as the db’s would try to do another HTTP Request to this same url, the database should immediately freeze again. (the databases ran fine for many months, and then suddenly all went kaput on this url)

I had to disable this http request call. A couple days later, I re-enabled it, and things worked fine. A week later, the same thing happened again: all databases hitting this particular url freeze.

  • some of the databases are on v16 (b230047)
  • some are on v17 (b233645)
  • some run the HTTP Request directly from 4D Server. (4D server then froze)
  • some run the HTTP Request from a 4D client work-station (4D client then froze)

The same thing happened to me a year ago with WEB SERVICE CALL on some URL’s: I ended up re-routing those calls through a proxy to manage the SSL for me: which fixed the issue.

I’ve now re-routed this particular HTTP Request through a proxy - to manage TLS for me.

I reported the issue to Tech support: but I have no way to re-produce.

So, it seems to me that somewhere, deep in 4D’s TLS handling, there is some condition that can utterly hard-freeze 4D. When I say hard-freeze: I mean it becomes totally non-responsive, and must be force-quit.

I’m putting this out there to see if anyone else has seen the same.

Never heard about that.

Internally the command HTTP Request is using OpenSSL to make the TLS
connection, which is widely used, so I believe the TLS handling is

Anyway, what also looks strange:


Even after a restart: as soon as the db’s would try to do another
HTTP Request to this same url, the database should immediately freeze

That more looks like firewall or other network parts. If it would be 4D, it would not happen again after a restart. What happens if you restart the computer itself?

Two more things to test on your side (beside computer restart) to help to track it down:

Insert always, or at least in a way you can enable it if it happens after you restart your 4D application for a second test:

(If the timeout is too long, it could look like a freeze.)
I’m not saying that this is your issue, I just want to exclude it.

Finally, prepare on the compute the usage of Wireshark.
When the issue happens again, quit 4D, start Wireshark, enable logging of communication to port 443, start recording, then start 4D and repeat.

Yes, I know that the recording is not readable (as it is encryypted), I just want to know if the other system answers, hoping this helps.

Then add this info to your TAOW case.