PizzaProgram

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 !🙂

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;

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! 🌞

I have a huge app (pizzaprogram) running for 20+ years rock stable on hundreds of PCs, written in Delphi7, using: AlphaSkin + Indy + UIB + TVirtualStringTree also had 5 background threads running without any problems. (Some of them are using UIB.) This year I've started to work with `OverbyteIcsSslHttpRest, OverbyteIcsLogger, OverbyteIcsSslJose, OverbyteIcsSslX509Utils, OverbyteIcsWSocket, OverbyteIcsSuperObject, OverbyteIcsHttpProt, OverbyteIcsUtils, OverbyteIcsSSLEAY` units, running in a 6th separated thread. Since then, every 1-6 hours my program is crashing with EOutOfResources whenever AlphaSkin is trying to create or resize a bigger Bitmap. I've upgraded AlphaSkin from 2019 version to latest, but it did not help. (Actually it made it even worth, because the new version is generating 32bit bitmaps for every form and panel and button forehead.) The private memory consumption of my EXE is always under <150MB , usually 75MB Peak Virtual memory size < 300MB GDI number < 900 Please give me some hint / advice, how could I solve this mystery?

[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'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" ?

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)

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! 😞

But now I have found a new problem with latest release: openssl.exe is not running on Win10 64bit PC, if only the 32bit DLL-s are present ! (This problem did not occure on prev. versions.) - What can I do? - Is there any "command line switch" to force search for the 32 bit DLLs ? (My app is 32 bit, I have now all the 32bit DLLs embedded into into, taking already lot's of space.)

... fixing the PATH problem was easy, ... p := exe_path + c_my_SSL3_base_dir; OverbyteIcsSSLEAY.GSSL_PUBLIC_DIR := p; OverbyteIcsSSLEAY.GSSL_DLL_DIR := p + '\2301'; // 'e:\myApp\Bin\SSL\202xxxxx\2301'; // add version number // GSSL_SignTest_Check := True; try OverbyteIcsLIBEAY.IcsLoadSsl; Result := True; except on E:Exception do logme('Failed to initialize SSL3 DLLs. Error message: ' + E.Message); end;

Yes, I fully understand all of it now. Thanks for the replay! The only 4 things are not yet clear to me: 1.) What is the command I can force this "unpacking" (+ initialization) of the resource-embedded DLLs ? 2.) Can I set a path before where is should happen? (I like to put those to my own APP's dir, like: MyExePath\Bin\SSL\20240205\dll ) 3.) ... If I want to do that, should I disable: {DEFINE OpenSSL_ProgramData} ? 4.) After resource unpacking / before each initialization if these DLL files: - Is ICS checking the file's integrity? (CRC32 or at least the size?) (Because I could list many cases when it does not succeed. (Write error, bad Antivirus program, modified by a malware, ... )

... hmmm that's interesting: Since the upgrade from v9.0 -> to v9.1 My EXE file (compiled under Delphi 7 ) increased from: 15.5 MB -> to 20.5 MB I'm using MPress to self-compress it, and it also shows a +21% size increase: 7.1 MB -> 8.6 MB That's a huge difference if we count that only pure code happened. (No new pictures added or similar, which would explain it) Well, it is not a very big problem, but there are still some restaurants having only 30-60Kbit internet max. (3G) ... and also a memory consupmtion on a Win32 tablet is +25% more. ... Investigating it further I've realized, there are new huge .RES files in the source directory. LibV32OpenSSL32.RES And so I've realized what all that means: I have red about in the 9.1 " what changed " topic, but did not comprehend, that the section: "Distribution of the ICS OpenSSL files has changed " is an extreamly cool upgrade Maybe re-writing it using my own words can help others too: The new 9.1+ ICS will force-include OpenSSL DLL files inside the compiled EXE by default. - It will extract these DLL files from the EXE on first run / initialisation to a common directory. - This behaviour can be turned off by editing the ...\ICS\Source\Include\OverbyteIcsDefs.inc file. - But it's not recommended because some features will fail to work.

Great 😉 I'd just like to report that: - it WORKS ! Both TSSLContext + JOSE + SuperObject + Utils. (Just made my first attempt to communicate with the government test server to send/receive some data.)

Hi, Thanks for the continuous update of this component package 🙂 I'm trying to update from 9.0 to 9.1 under Delphi 7 , but it won't compile: [Error] OverbyteIcsSslBase.pas(494): Undeclared identifier: 'TBytes' Is there a quick-fix for that ? EDIT: [SOLVED] Just added this line: unit OverbyteIcs....; interface ... OverbyteIcsTypes, { V9.1 } To these files: OverbyteIcsHttpAppServer.pas OverbyteIcsIpUtils.pas OverbyteIcsSslBase.pas OverbyteIcsUrl.pas

I've searched 2 hours long for an answer: - What is the main difference between OpenSSL 3.0.x / 3.1.x / 3.2.x / 3.3.x ? Here is what I've found: The main difference is the support time vs. speed issues vs. new features. 3.0 was reported to be slow, but it will get the longest support (LTS): 2026-09-07 3.1 is a "middle solution", much faster but shorter support: 2025-03-14 3.2 is currently the recommended version, (but it has shorter support time than the LTS): 2025-11-23 1.1.1, 1.1.0, 1.0.2, 1.0.0 and 0.9.8 are now out of support and should not be used 3.3 is only at alpha state yet.

Please advice me where I could find a "simple download" example of ICS v8.70 ? I'm still using Delphi7, so I was told it is not recommended to update to the new 9.0 version. With Indy10 it was extremely simple to do: IdHTTP1.ConnectTimeout := 2000; try FS := TFileStream.Create(save_path, fmCreate); except Exit; end; try //'http://...' IdHTTP1.Get(theURL , FS); if IdHTTP1.ResponseCode = 200 then ... ... Also I was able to update the request status + the progress: function get_httpStatus(const AStatus: TIdStatus; const AStatusText: String): string; var s: string; begin case AStatus of hsResolving : s := 'Webszerver (DNS) keresése...'; hsConnecting : s := 'Kapcsolódás a webre...'; hsConnected : s := 'A kapcsolódás sikeres.'; hsDisconnecting : s := 'A kapcsolat bontása'; hsDisconnected : s := 'A kapcsolat BONTVA.'; hsStatusText : s := 'Állapot:'+AStatusText; ftpTransfer : s := 'Adatáttöltés...(FTP)'; ftpReady : s := 'Készen áll az adattöltésre (FTP)'; ftpAborted : s := ' ! MEGSZAKÍTVA !'; end; Result := s; end; procedure TFrm_myDownload.IdHTTP1Status(ASender: TObject; const AStatus: TIdStatus; const AStatusText: String); begin lbl_status.Caption := get_httpStatus(AStatus, AStatusText); lbl_status.Repaint; end; So how do I do the same with ICS? - need timeout - need progress update (not the ICS progress bar, but my own) - need status update (localized!) PS: I've spent ca. 30 hours so far reading FAQ + Getting Started + opening and analysing the examples inside ..\ICS\Samples\Delphi directory, but found nothing, except: - the "OverbyteIcsHttpMultipartDownload.dpr", which ended up with catastrophe: PS2.: [edit] Also used "search" on this page with multiple keywords, checking 200+ topics, but found no answer.

Hmmm... that's interesting and promising, because I have compared: OverbyteIcsHttpsTst1.pas with OverbyteIcsXferTst examples and maybe my problem is, that I'm using TIcsHttpMulti component instead of a simple TSslHttpCli. It seems that the "multi" version calls SSL initialization automatically inside .Download() method. (I'm not calling it from anywhere before starting the download.) So the solution seems to be to get rid of this nice "multi-download" component and use a simple CLI. Thank you VERY VERY much for all the time You have invested to test it for me and to write it down in this topic! :-)))) Good Night!