Angus Robertson

You don't download OpenSSL using ICS, you use a normal browser. 

But you already have OpenSSL, it is also distributed as part of ICS, in the openssl folder, and the DLLs are also in the sslsamples folder so all the ICS samples work. 

You just have to make sure the DLLs are in the same folder as your exe, unless you specify a different folder in code. 

Angus

The websocket protocol has a keep-alive feature, if data is not being sent regularly, it is designed to be kept open.  ICS does this for websocket client and server.  

ICS is quite capable of keeping sockets open for hours, but unless there is some traffic external routers and caches may decide the connection is dead and close it, I had to fix an FTP control channel issue where it was unexpectedly closed after a two hour upload of 50GB, needed to send keep-alives.  That was annoying and time consuming, the 50GB uploads worked, but because the control channel was dead were considered failed.

But here we are talking about a simple web server, the HTTP protocol allows keep-alive connections usually closing after a couple of idle minutes, I'm not aware it allows hours long connections without any traffic, and certainly the ICS web server is not designed or tested for that concept.

Angus

I see a project, without any explanation of what you are trying to achieve or how to use it. 

You have previously mentioned holding open client sessions for long periods, without saying how or why you are trying to do this. Web servers don't hold open connections. 

Then the server itself closing when a client closes? 

Sorry, without details, I can not investigate anything.    

Angus

Thanks, I've made the change in my copy, but it won't be in SVN for several days until I see if it breaks anything. 

Generally, applications use specific events like onSessionConnected, Closed, etc to check for errors, rather than the State changing.  But if this change proves not to be backward compatible, it will be reverted.

ICS itself does not use the OnChangeState event, except for when a server starts listening. 

Angus

I've got a twin Dymo label writer, and still use the v8 label software, I have a setup file dated 2014 (113M) if you want to install the old version. 

But never tried to use it from Delphi, not aware type libraries have changed, that sort of stuff tends to be stagnant in terms of development. 

Hardly use the Dymo now, was excellent for printing postage stamps in the UK, but that service ceased years ago, as did using the post in general.

Angus

You are using an old version of ICS, all gettickcount functions now use Int64. 

    FConnectTick  : Int64;       { V8.71 changed from cardinal to Int64 }
    FLastRecvTick : Int64;       { V8.71 }
    FLastSendTick : Int64;       { V8.71 }

ICS has supported In64 ticks on all Windows platforms since 2009 using the OverbyteIcsTicks64 unit which uses QueryPerformanceCounter for ancient operating systems, although Cardinal ticks were only fully removed for the latest release. 

Angus

The DLLs will probably end up in a similar place to the existing sample INI files, which works well, unless you want to find them manually...

Angus

Quote

Alas, the most stable solution is to extract libs to files and then load them normally.

Which is what I'll do for the first version, may experiment later with memory loading, but don't plan to spend much effort on it.

Angus

But those five minute client connections are not shown in either of the logs you posted.  How do you know the server closed the connection, and not the client, windows or a router? 

Angus

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

Quote

Do you really need to store the DLLs in your EXE to begin with? 

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

The TSslHttpRest file upload feature is designed to replicate a web browser uploading a file from a web page using a Submit command.  

You can see how the MIME content is built in the TSslHttpRest.RestRequest function at line 2910 in OverbyteIcsSslHttpRest.pas, you'll need to build a similar post stream before calling the component with your own Json requirements. 

However, your description of needing a 'full local path to the image' seems strange, unless your REST request is to a server on the same PC, normally you'd expect to send JPG image data or something, not a file name,  

Angus