Leaderboard

Use full (absolute) path for JpgFileName and dest_path, such as F:\img etc.

Never rely on relative path names! They depend on whatever the application thinks the "current directory" is, and that is frequently not what you think it should be. Have you checked what destPath contains after your assignment?

Which version of the DLLs are you using, though? TIdSSLIOHandlerSocketOpenSSL supports OpenSSL 1.0.2 or earlier. If you are trying to use OpenSSL 1.1.x or later, you need to use this SSLIOHandler instead: https://github.com/IndySockets/Indy/pulls/299 The only issue I see with that code is you are creating the SSLIOHandler conditionally. You don't need to do that, you can access non-secure HTTP urls even with the SSLIOHandler assigned. TIdHTTP will handle the underlying TCP connection and SSLIOHandler.PassThrough property for you on a per-request basis, (re)connecting and toggling between TLS/non-TLS as needed. Because of that management, when you do create the SSLIOHandler, you don't need to set its PassThrough property manually at all. The SSLIOHandler will also handle loading the OpenSSL DLLs dynamically only when they are actually needed, so if you never request an HTTPS url then the DLLs won't ever get loaded, and PassThrough will always be True. So, I would suggest just getting rid of your UseSSL config option altogether, it is really not necessary. In fact, it will actually cause a runtime error if it is set to False and then you request a non-secure HTTP url that redirects to a secure HTTPS url. So, best to just have the SSLIOHandler assigned unconditionally instead, so it is always ready to go in case it is needed. procedure THSJSonApiClient.InitHTTP; begin fhttp := TIdHTTP.Create(nil); fopenssl := TIdSSLIOHandlerSocketOpenSSL.Create(fhttp); fopenssl.SSLOptions.VerifyMode := []; fopenssl.SSLOptions.VerifyDepth := 0; fopenssl.SSLOptions.SSLVersions := [sslvTLSv1_2, sslvTLSv1_1, sslvTLSv1]; fhttp.IOHandler := fopenssl; fhttp.handleredirects := True; {$IFDEF DEBUG} flog := TIdLogEvent.Create(nil); flog.ReplaceCRLF := False; flog.LogTime := False; flog.Active := True; flog.OnReceived := CatchLogReceived; flog.OnSent := CatchLogSent; flog.OnStatus := CatchLogStatus; fhttp.Intercept := flog; {$ENDIF} end;

By default, Indy uses OpenSSL. When that error happens, you can use the WhichFailedToLoad() function in the IdSSLOpenSSLHeaders unit to find out why. But note that Indy does not support OpenSSL 1.1.x yet, so you would have to deploy OpenSSL 1.0.2 dylibs with your app, and then tell Indy where those dylibs are located at runtime via the IdOpenSSLSetLibPath() function so it can find them. Also look at the IdOpenSSLSetCanLoadSymLinks() and IdOpenSSLSetLoadSymLinksFirst() functions to make Indy avoid loading dylibs for other non-compatible OpenSSL versions. In any case, be aware that ever since Google dropped support for OpenSSL in Android 6 in favor of BoringSSL, using OpenSSL on Android is increasingly difficult. The above MAY OR MAY NOT work, depending on the device's setup. Indy does not support BoringSSL at this time, or any of the more official higher-level Java APIs that Google wants developers to use instead of using lower-level native libraries, like OpenSSL/BoringSSL directly. The alternative is to write your own TIdSSLIOHandlerSocketBase-derived class (or find a 3rd party one) that uses whatever SSL/TLS library/API you want besides OpenSSL. For example, there is some effort in progress to add support for LibreSSL/LibTLS to Indy, though I don't think that will help you in this particular situation, but it shows that supporting alternative SSL/TLS APIs is possible.