Angus Robertson

The new log does not show any client connections. If you wish me to investigate an ICS problem, I need to be able to reproduce that problem or have extensive logs that clearly illustrate the problem such that it can be found and fixed. Those logs need to be annotated to show what I'm supposed to look at to see the problem. The current ICS samples don't log sufficient detail to show when and why connections close, and why the server has been closed. That information has never been needed, since the servers have been running in various versions for 20 years without unexpected closing being reported as a problem. Angus

My plan is to build the OpenSSL resource file at the same time as signing the DLLs and distribute them together in the zip for each new release. The latest resource file will also be part of the ICS distribution alongside the latest DLLs. ICS will only support OpenSSL 3.0 and later, versions will under support. The resource files will have the three DLLs, licence file, and a version string, used for the path when extracting the DLLs into a temporary directory. Is there anything else that would be useful to allow other projects to use the same OpenSSL resource files, to avoid building their own? Angus

The log shows several sessions from an older VCL web server sample, it does not log when buttons are clicked to start and stop the server. The two GET requests are closed after a few seconds, the server was closed about 90 seconds later, no idea why but unconnected to the client closing. I don't see any client connections held open by the browser, and certainly nothing closed after five minutes. The FMX IcsSslMultiWebServ sample has better logging straight to file, particularly when the Display HTTP protocol box is ticked, but does not log time stamps nor sessions closing, so would need some updating to log the problem you seem to be having. Angus

Using the IcsSslMultiWebServ sample I asked you to test? Can I please see the server log file? Angus

Thanks all, BTMemoryLoadLibary and BTMemoryGetProcAddress would appear to be the solution, but do add a lot of extra code. I think I'll implement the simpler save/load resource first, which will be conditional, then look at adding more conditional code to optionally load directly to memory. Ultimately, how to build applications is up to the developer. The OBJ solution is best, it's called YuOpenSSL, but is not a simple compile of the OpenSSL C code, lots of macros and other issues. Angus

All your questions have been answered previously, more than once, and today again. Angus

My earlier comments did state this is an old unsupported component, with better modern components. Angus

ICS v9.0 has been tested on Delphi 7, and future versions may still work on Delphi 7 but will not be tested or supported, I can not justify my unpaid time to support 20 year old tools that lack language features in Delphi 2007. From the ICS readme file about client samples: OverbyteIcsXferTst - File copying, FTP upload and download, HTTP download, using TIcsFileCopy, TIcsFtpMulti and TIcsHttpMulti This sample downloads multiple HTTP files with progress display and logging, I wrote it almost 20 years ago. There is also a very simple example in the new OverbyteIcsSnippets sample, function doHttpDownListClick that downloads three files with progress information, only 50 lines of code with a single function call HttpMultiClient.Download. Angus

Assuming you don't want to upload a file, you should change the code you showed to remove TMultiPartFileReader, just build a single MIME block from your header and footer, change capture.jpg to your full file name in s. and use the string as raw parameters in the REST call, which will automatically create the SendStream for the request. RestRequest(httpPost, URL, False, MyMimeHeaders); Angus

Can any other ICS C++ users reproduce this Win64 issue? If no-one is willing to help us support C++, I'll have to remove C++ support from ICS. Angus

The TMultiPartFileReader class you have used opens and converts file content to MIME base64, for a file upload. Earlier, you said you didn't want to upload the file. But I'm still waiting for you to show an actual example of the data you are trying to POST. Angus

We are providing component libraries for others to built SSL capable applications, and avoiding DLLs does come up regularly, it should be an option that other developers can use or ignore. The best solution is YuOpenSSL which is OpenSSL compiled into a DCU so no DLLs. It does increase application size, probably the same as using resources, but generally applications using OpenSSL distribute their favourite version of the DLLs in their application directory, so you end up with numerous similar DLLs all over the place. But YuOpenSSL is a lot of effort to maintain and is therefore a commercial product not everyone wants to buy. In theory, the OpenSSL resources only need to be written to files once, but making sure those files are the latest or oldest versions may be challenging. Angus

I'm looking at adding the OpenSSL DLLs as resources to ICS projects, to simplify distribution to one file. But currently it seems a DLL can only be loaded using the LoadLibrary API from a disk file, so the resource has to be written to disk first then LoadLibrary used. It would be faster to load the resource straight to memory, but there does not seem to be an API that does the magic of LoadLibrary for a memory address, need a handle to the library so that exports can be loaded. A little Googling suggests some hacking techniques might work, but with the risk that AV software might take a dislike to the application. Any simple solution, or do we have to live with temporary files? Angus

Thanks, effectively this site seems to be requiring the same parameters as a web browser submit form, rather than the more normal content used by REST APIs. The ICS TRestParam class can already generate seven different content types, Json, UrlEnc, XML, CSV etc, so I need to add FormData as an eighth content type, I'll look at it next week. Effectively this will be a more generalised version of the file uploading code I already recommended, but without actually uploading a file which it seems was a red herring. Angus

I don't know anything about Postman. If you are not sending a binary file, there is no point in using MIME. It's just a simple REST request. I need to see what HTTP data Postman creates, not what the GUI says, to make any sensible suggestions. Angus