Angus Robertson

All your changes, and some other USE_SSL issues, were in SVN last night. The final release is today once I complete the documentation. Angus

I don't use patches that have no explanation of their purpose or from unknown versions of ICS. But I will check my next build finds the same fixes. Angus

BTW, the USE_SSL conditional is a historical curiosity from 15 years when SSL support was optional. Today it's only purpose is to make programs that don't need SSL a little smaller, but makes the source code bloated and hard to maintain, all new ICS components only build with USE_SSL. So future support of USE_SSL is unlikely, it wastes too much of my time. Angus

Very few ICS applications work without SSL, so testing without SSL and without many of the other obscure settings is very low priority, done only before major releases or when people actually report specific problems, which I don't recall you doing previously. I will test without USE_SSL before the next release and fix any issues. Angus

The last V8.5x release was two years ago, and I have indeed compiled one or two programs using ICS in that time. Angus

There are more authentication methods in newer ICS versions, not sure which method you are using, but you can still add your own header the same as your old application, and do use the logging event, makes debugging so much easier. Angus

With the TSslHttpRest component, you don't need an SslContext, you just set HttpRest.SslCliSecurity to one of the 14 TSslCliSecurity types, like sslCliSecTls12 for TLS/1.2 or better, and all the context options are set. other options force TLS/1.0 is you want to check is old stuff is supported, etc. BTW, recommend you use TSslHttpRest from V8.65 in the overnight zip, it has a large number of improvements over V8.64, and will be finally released next week. Angus

You don't say what errors or exceptions are reported, so no idea whether the problem is the client or server. Your code is the old way of doing this, recent versions of ICS have a new TSslHttpRest component derived from TSslHttpCli that handles all send and receive streams internally (and SSL context),, and has logging built in. There is a new OverbyteIcsHttpRestTst sample that should allow you test your request and see the result, also the OverbyteIcsSslHttpRest unit itself has several example of using TSslHttpRest to access Google, Twitter, Microsoft and other REST APIs, the code for sending a Json email is as simple as:: HttpRest.RestParams.Clear; HttpRest.RestParams.AddItem('raw', IcsBase64UrlEncode(Content)); HttpRest.RestParams.PContent := PContBodyJson; HttpRest.ServerAuth := httpAuthBearer; HttpRest.AuthBearerToken := FAccToken; HttpRest.DebugLevel := FDebugLevel; StatCode := HttpRest.RestRequest(httpPOST, EmailURL, False, ''); FResponseRaw := HttpRest.ResponseRaw; FResponseJson := HttpRest.ResponseJson; This is a sync request, so does not return until the request is done, but the third boolean argument makes it async. No events are needed, you write ResponseRaw to a file if you really need it saved. Angus

Two new zips for Win32 and Win64 versions of OpenSSL 1.1.1e can now be downloadable from the Wiki at: http://wiki.overbyte.eu/wiki/index.php/ICS_Download or https://www.magsys.co.uk/delphi/magics.asp . The latest 1.1.1 DLLs are also included in the ICS distribution SVN and overnight zip. This release includes one low priority security improvements and bug fixes, including one that allows IcsJoseJWKPubKey support RSA-PSS keys. ICS applications require V8.57 or later to support OpenSSL 1.1.1e. Changes in 1.1.1e may be found at https://www.openssl.org/news/openssl-1.1.1-notes.html Angus

Updated OpenSSL to 1.1.1i, fixes a high severity problem reading specially crafted malformed SSL certificates that could cause OpenSSL to crash, also minor bug fixes. The same high severity problem happens in 1.0.2 and 1.1.0, but these are out of support so users should update to 1.1.1. Angus

These memory leaks are now fixed in SVN, will be zipped overnight, thanks again. Angus

In TWSocket, most errors are reported to event handlers, where 0 means no error. OnSocksError should only relate to proxies, so you don't need that. onBgException is for errors for which there no event handler involved, background message handling, etc. If OnError is assigned, it stops an exception being raised for some errors, like send data failing, so you need to check function return codes carefully. Angus

You can also check if a new client connection is from the same IP address as an existing client and use that to close the stale connection. TWSocketClient has a property CPeerAddr you can read. Angus

The best solution is for your clients to regularly send something to the server, easy if you write the client code, then you use the last data received tick on TWSocketClient to timeout the connection and close it. The HTTP server has such a timeout. Second best is for the server to send data to the client regularly and check there is no error after 45 seconds or something, then close. If sending data upsets the clients, you can try pinging them which is much faster, but only catches network failure rather then the TCP session being lost. Angus

Thanks, will do the changes next week. In future, can you please add a patch text attachment, I know from experience that trying to use HTML Unicode for patches in Delphi causes corruption. Angus

The onDataAvailable event has knowledge of the data being received, unless you set LineMode to true, you just read all data into a buffer and process it later. If binary data is not received, that is an application error. Angus

If the database uses stored procedures to isolate the business functions from underlying data and verify input, data, then having the REST API match the SPs would save a lot of coding, But since most real databases are relationship based with multiple tables, you don't really want that functionality in browser Javascript. Angus

So almost the same as my ComCap application, which works fine without threads, except for adding the captured data to a SQL database which is queued then added in a thread. Read my previous message again. Angus

Not sure what this has to do with this thread. Suggest you look at the OverbyteIcsProxySslServer.dpr sample. The ICS proxy component can be used as a forward or reverse proxy with logging. Angus

I have a commercial ICS application called ComCap with multiple clients accepting data from SSL servers and forwarding that data to other SSL servers, all without threads, it has retries for lost connections. It makes heavy use of the TIcsIpStrmLog component which runs as a client or server, and has been tested with over 1,000 simultaneous sessions, no threads, no exceptions. Suggest you look at the OverbyteIcsIpStmLogTst sample and see if you can simplify your application by using TIcsIpStrmLog to replace your TWSocket and TWSocketServers compoents. Angus

Just build the OverbyteIcsProxySslServer sample, and edit the INI file to point to the correct SMTP server. Angus

You can use a stand-alone proxy server such as STunnel running on the same network to accept connections on port 25 and send SSL to port 465, you don;t need a full SMTP server. ICS has a proxy sever component that does exactly that (I use it for an old email client) but we only support Delphi 7 and later. And using ICS, you'd now use TMailQueue instead of an SMTP client since it queues mail to multiple SMTP servers. Angus

The 401 response is expected for Digest and NTLM, there is a challenge returned, you can never avoid it. The only issue is if you only need to accept it once. Angus

Probably not the answer you want, but the ICS library has a component TIcsMailQueue which sends emails from a directory of EML files (not MSG), using multiple SSL SMTP servers and retrying until sent. But it only parses the EML files sufficiently for the SMTP protocol. There are other components for reading mail headers and bodies. Angus

The component is auto selecting httpAuthDigest for which it requires the challenge sent in the 401 response, the component does not have any way of storing the relaam, nonce and other stuff. Not sure if the same Authorization: header can be used more than once for subsequent requests, never used Digest myself. You'll need to check Wireshark on the other application to find out where it finds realm, etc, or if it uses a different authentication mechanism. Angus