PizzaProgram

Closing the socket every each time before a new REST request, kills the concept of : "do not have to re-re-re-reconnect to the same server and re-re-reinitialize SSL". I think it would be logical to keep the socket as long as it works, (sometimes for days), but kill it when there was an error. That was my question about: Do I have to take care of that manually by default? Or did I find a bug in the component that is very hard to reproduce? How about something like this? try SslHttpCli3.StatusCode := 0; SslHttpCli3.Get; except on E:Exception do begin errorTxt := E.Message; try SslHttpCli3.CtrlSocket.Close; except end; end; end;

I would like to ask for a tiny help, because I do not know ICS well enough yet to find a solution for this... 👼 I've switched from Indy to ISC a few weeks ago. It runs only on a few PCs yet so I can test it's durability. But it's not stable enough yet, because sometimes, when the server is temporary overloaded I experience a strange behaviour: (By "sometimes" I mean after a few days of run. So I can not debug it, only read the logs of clients on remote PCs.) 1. failing attempt: httpGET: Error #8 -- Request aborted on timeout 2. attempt: (after 20 sec) 0 byte answer, no error msg. 3., 4., 5., ... all the attempts after that: httpGET: Status #404 -- Cannot change SocketFamily when not closed or in DNS lookup httpGET: Status #404 -- Cannot change SocketFamily when not closed or in DNS lookup httpGET: Status #404 -- Cannot change SocketFamily when not closed or in DNS lookup ... forever ... and the only way I can fix it, by restarting the program. Here I've shared my code using TSslHttpCli before: I was told not to destroy and recreate ICS component every each time before using it, like I did with Indy. But in that case: Why ICS does not reset itself / the socket, after first (timeout) error ? Do I have to create: some kind of "onTimeout" function for it manually, and close the socket myself? (I'm guessing that the socket is still open, and that's why it's causing trouble to re-connect. Right?) Why does my function's Result is True after such error, while the "error" text is clearly showing there was a big problem with the request? (The only case this can happen, if Statuscode is 200 or 400. Not #8 or none or #404.) Do I have to set: SslHttpCli3.StatusCode := 0; each time myself before calling .GET ? (Otherwise I do not see, why I do get a "True" as result.) Thank you very much in forward for any insight / help / idea !🙂

OFF: 📴 I absolutely agree, that it is very hard to apply new features, while maintaining backward compatibility. @EugeneK I was also freaked out from this change, took me 40+ work-hours to realize, debug, understand and adapt my code to it. It would have been nice, if it would have appeared first only as an OPTION, (disabled by default,) with a big fat red warning on the main page, that the next release will be default to this behaviour, so all of us could have been prepared... But now I like it. It's a great new feature. Resolves a huge problem: - "How to download DLLs from internet from a https site, without SSL DLLs present." So I'm very grateful to the developer maintaining and improving this component, and sharing it with us! 🌞

[Final Solution] <= v9.1 There must be 4 things manually programmed, to prevent memory violation when running ICS (SSL CLI) in background threads: Set MySslHttpCli.MultiThreaded := True; Create one global component in the main-thread at program start, and initializing OpenSSL3 DLLs from there. OverbyteIcsLIBEAY.IcsLoadSsl(); Destroy that global component only at program end. (This way OpenSSL can stay in memory, and initialized only once.) Create and initialize ICS components only inside the EXECUTE method of background threads ! (Otherwise the web-calls will still run in the main thread. Reason: ICS is uning Window handles.) Recommendation: - Create a fail safe code inside procedures where get / post etc is being called: if GetCurrentThreadId <> SslHttpCli3.ThreadID then raise Exception.Create('! ERROR ! SslHttpCli component of ICS is called from a different Thread! Not the one it was created: ' + IntToStr(SslHttpCli3.ThreadID)); ... until next release of ICS (>= 9.2? ) does it automatically.

I would like to report once again: - Since the last 14 days NO MORE PROGRAM ERRORS occurred any more caused by ICS running in background thread . - running on 100+ PCs I strongly suggest implementing those 3 fail-safe lines of codes at the next release, to prevent such behaviour ! (Because it took me 8+ month and many gray hair to find out what's causing it and how to fix it. Also there is no written warning about these anywhere.)

Dear @Angus Robertson , 🙂 Where You able to fix the problem by: - Renaming the openssl.exe to openssl-x64.exe for the 64 bit version - Leaving openssl.exe for 32 bit. (because it's compatible with both) This way even if you copy the content of the 32 + 64 bit ZIP files together, the one will not overwrite the other! (As it happened during preparing this 9.1 ZIP file on your PC.) Re-creating the v9.1 ZIP would be nice too, but at least prepare the: v9.2+ please, (so such overwrite never happens again.) Calling a 32bit exe on a 64bit OS is not a problem. (But the other way around it is bad.) TODO: - Copy both EXE files (openssl.exe + openssl-x64.exe) to the (next) ZIP files, you release. Thank You in forward!

What I still don't know: Should I set myGlobalMainCLIcomponent.MultiThreaded := TRUE; for the Main thread's component too ? Or only for those running in the background thread ?

Well, I'm shocked. You were right! I've moved the creation of the components from the initialization part to the Execute procedure and It's the same fast now as Indy. Also this will probably explain WHY my application crashed always ... (link to prev. topic about this problem) Thank you very much for the help! I truly recommend, the future versions of the component should check, and raise an error if: The creation and running thread are not the same? The first initialization (of loading SSL DLLs) and final destruction is not running in the main thread! Property of .Multithreaded is True while running in a background thread? (Can be automated too.) It's not just me, who recommended that:

Thanks for all the answers ! To clarify things: Yes, I create those components in the background threads. Each thread = each separate http component. 👼 No, it would be a big mistake to put everything in the main thread. 🤯 This is a POS program with a max user-response time of 50-100ms of the Main thread. (And there are 4-5 background threads doing different things, like DB-locking, DB-searching, DB-executing+ commiting + order cashing, menu-syncing, Logging, CallerID, Syslog, etc. So blocking the main thread would be more than problematic.) Seriously, I do not try to blame anybody, both components are excellent works ! Congrat to both of you and I'm really glad I can still use my old delphi7 for such complex things, like web-server + https. But that time increase from 580ms to 1560 is not normal, and I'd like to dig to the bottom of it. - Is there something maybe misconfigured? - Why does the 2th, 3th, etc call of ICS taking the same time as the 1th? I do not destroy the component, do not tell it to disconnect, so the socket should be established to the same domain, only some sub-parameters of the URL is changing ! So theoretically the speed should shorten after the first connection. - Opening the URL in a browser: Firefox time measure shows = 560ms too, so that is the standard server response time. - (Ping to the server is constant 2ms)

I've finally finished to rework all my codes, so it works both with old Indy OpenSSL 1.0.2 and latest ICS 9.1 (OpenSSL 3.2) by setting a simple checkbox (UseSSL3?) But when I test it, it gives odd results, because it takes 3x so much time to download a simple XML with ICS now. Old Indy download time = 560 - 570ms New ICS download time = 1560-1580ms I have tested it many many times, same results. - Both components running in background thread. - BasicAuth (username + password) is used. - Indy component is getting created each time before download. But ICS (+SSL initialization) is done only once before thread start. The code I use is very simple: function Get_with_SSL3(const url: string; SslHttpCli3: TSslHttpCli; var Data:TMemoryStream; var error: string; timeOut: integer): Boolean; var size: Int64; begin Result := False; if Data = nil then Data := TMemoryStream.Create; SslHttpCli3.URL := url; SslHttpCli3.Timeout := timeOut; try try SslHttpCli3.Get; except on E:Exception do // 400 error := E.Message; end; finally Result := (SslHttpCli3.StatusCode = 200) or (SslHttpCli3.StatusCode = 400); size := 0; try if Assigned(SslHttpCli3.RcvdStream) then begin SslHttpCli3.RcvdStream.Seek(0, soFromBeginning); size := SslHttpCli3.RcvdStream.Size; end; if size > 0 then begin Data.Clear; Data.LoadFromStream( SslHttpCli3.RcvdStream ); end else error := 'ERROR! 0 byte answer. ' + error; except on E: Exception do hiba := '! Stream read error: ' + CRLF + E.Message; end; if Assigned(SslHttpCli3.SendStream) then SslHttpCli3.SendStream.Size := 0; if Assigned(SslHttpCli3.RcvdStream) then SslHttpCli3.RcvdStream.Size := 0; end; end; Is this "normal" ?

A Solution would be in the next release: (9.2 ?) - Please rename that openssl.exe to: openssl-64.exe - and include the 32bit exe in the component-pack-ZIP too please ! - Even better, if both EXE files would be also auto-embedded, just like the DLLs. They are small compared to the whole directory combined. Thank You all for the help!

Thank you very much for the quick replay! I've double checked, and triple checked, and realized, you where right! About the problem, why I was mislead: On this site: https://wiki.overbyte.eu/wiki/index.php/ICS_Download There is only one ZIP available of 9.1 download for Delphi7. Inside that ZIP there is only one ICS-OpenSSL folder. (Containing both 32bit and 64bit DLLs.) Inside that folder there is only one openssl.exe file. (No separate 32/64bit versions of it.) I've also checked, who made the digital signature for DLLs and the EXE: - They are signed by the same company (Magenta Systems Ltd) nearly the same time. (21 sec. difference) I've also checked the other ZIP made for new Delhpi versions: https://wiki.overbyte.eu/arch/icsv91-new.zip But there is exactly the same structure. So basically NOTHING IS INDICATING, that this exe is only for 64 bit ! But if I scroll down to the bottom of the page and download the binary file separately : https://wiki.overbyte.eu/arch/openssl-3.2.1-win32.zip That openssl.exe has a smaller size! (814k)

I know! That's why do not understand, why this new openssl.exe is behaving differently?

Thank You very much for trying to help, but I'm talking about hundreds of PCs, that needs to use this exe every few year once to generate new keys. Deploying all those missing DLLs by hand to every each PC one by one would be an insane big task. If there are 32 bit normal DLLs present in the same directory, the EXE should have had recognise and use those, just like it did before this new version. Of course, as a programmer myself, I can make some "dirty hack-solutions" to circumvent the problem, (which will probably cause other problems,) but it's just not the way it should work! 😞