Angus Robertson

He originally posted the question in the ICS forum, but the issue is not with ICS, but with a Javascript web page implementation to display data from the websockets server. Angus

You know ICS is sending the data, so the issue here is your Javascript to receive the data. You say you are using the ICS sample HTML page, why do you think it is designed to receive data from the server? Angus

I've been using Axolot Data XLSReadWrite to read and create XLS and XLSX spreadsheets for almost 20 years. Not free, but just works. http://www.axolot.com/ Angus

Sorry, I did not write the WebSockets component, and only minimally tested it. Perhaps someone who actually uses WebSockets will have a suggestion. Angus

Sorry, other sample not in the main project group that is a victim of functions moving between units to ease linkage. Please just add OverbyteIcsUtils to the OverbyteIcsWebSockets uses clause. Angus

This is now fixed, should be in SVN tomorrow with a lot of other HTTP improvements. There is a new option to skip removing the # fragment anchor where users are deliberately using # as a parameter without escaping it. But this is likely to be so rare the option has to be set to leave it, so technically not backward compatible which is our development philosophy. Angus

# is an anchor, an instruction to the browser on how to display the page, it is never sent to the server as part of the URL by a browser. Your application should create a valid URL by removing the #. ICS does not validate the URL for illegal content. Angus

OpenSSL has released new versions of the two supported branches, 3.0.3 and 1.1.1o, Windows binaries are available from http://wiki.overbyte.eu/wiki/index.php/ICS_Download or https://www.magsys.co.uk/delphi/magics.asp . OpenSSL 3.0.3 fixes a moderate security risk relating to the OCSP_basic_verify function but using an option ICS does not use, a low risk problem with an incorrect MAC key used in the RC4-MD5 cipher suite but which would never be used on modern connections, and a low risk problem with resource leakage when decoding certificates and keys and clients and servers configured to accept client certificate authentication, which might eventually run out of memory. Separately YuOpenSSL has released both these versions as commercial DCUs allowing applications to be used with OpenSSL without needing separate DLLs. Angus

ICS does make increasing use of TBytes internally, so adding an overloaded Send would make sense, a few days. You can always pass a code page to SendStr, that is another overload. Angus

I am still seeing those debug lines in my main web server application, but not in two other ICS sample web servers. But this is purely something I see under the Windows 11 debugger, the server itself on two Windows Server 2018s is handling tens of thousands of requests daily and one Windows Server 2022. My other Windows 11 DNS problem turned out to be no gateway on one of the two network adapters. Angus

ICS includes an updated version of THTMLParser from Dennis Spreen 20 years ago, very simple, just works. https://svn.overbyte.be/svn/ics/trunk/Source/OverbyteIcsHtmlPars.pas Angus

RcptName name is used for the SMTP protocol, HdrTo is used to build the message header, and it is normal for that to have friendly name and email address. The component does not add them together, although some SMTP forwarders and POP3 servers may do so. RcptName is sometimes added by servers as X-To: header or similar. Angus

I don't test OverbyteIcsDDWebService for each new release because it has dependencies outside ICS, but it is next on my list to add support for OCSP, next week as well. Angus

I did some initial testing, and the version of OverbyteIcsSslMultiWebServ in SVN has the comment 'Added authentication using POST requests.' There were no relevant changes to the server itself. But I'll be doing some more work on POST uploads and authentication next week, so will test it again before the next release. Angus

I'm not sure that this is actually a problem, since ICS already has various derived components like: THttpAppSrv = class(THttpServer) which don't give any errors. But I don't see any purpose in setting the name FWSocketServer.Name either, it might have been used for debugging a long time ago, but I've just removed it from my copy so your problem will go away, unless anything thinks the name is needed? Angus

Done a little more research, to connect to this site needs literal SslOpt2_LEGACY_SERVER_CONNECT adding to SslContext.SslOptions2. With OpenSSL 1.1.1 this defaulted set, but with 3.0 is not set due to: Angus

I'm now seeing the same 'unsafe legacy renegotiation disabled' error on both sites with OpenSSL 3.0, but that error did not happen with 1.1.1. So better, but not really fixed unless it really is an OpenSSL error that few other sites show up. Angus

I added the TSslHttpRest REST component four years ago, to speed up application development by combining several other ICS components needed for HTTPS applications together and building parameters in various ways. It is used for OAuth2 authentication, TIcsTwitter, TIcsRestEmail (Gmail and Outlook), TDnsQueryHttps, TIcsSMS, TIcsInetAlive and SSL/TLS certificate ordering TSslX509Certs. The last ICS TSslHttpRest release added various file downloading strategies, including resuming failed partial transfers, the next TSslHttpRest release will add various file uploading strategies using POST including multipart MIME with metadata content. Ideally, there will be new components to simplify access to various cloud services, ie TIcsMsAzure, TIcsGoogleCloud, TIcsAmazonCloud, TIcsOSSwift (Open Stack), TIcsMsDrive, TIcsDropbox, perhaps TIcsWebDAV if still used. I'm old-fashioned, I don't use any cloud facilities, I just have hosted Windows servers in a rack running the ICS FTP server for all my own upload and download needs. So supporting these various cloud protocols needs research and accounts, and a lot of reading and testing, and decisions of which specific APIs need support from a component. But I guess various ICS users are already using one or more of these cloud providers with their own applications, perhaps also with non-ICS components. Ideally I'd like such users to take ownership for developing and testing the component for a specific cloud service, based on a common template, while I update TSslHttpRest to support the extra features like multipart MIME needed, So is anyone using ICS for cloud storage? Angus

Sorry, I did say I was unable to connect to depatisnet.dpma.de with either version of OpenSSL, it was www.dpma.de that connects with 1.1.1 but not 3.0. Not sure what this means, could be OpenSSL has improved security that now breaks the site. depatisnet.dpma.de appears to be configured differently, so always fails. Someone using Wireshark may be able to interpret the handshaking, but that won't fix anything. It's frustrating that the browsers work, why? You could try looking for a proxy that works, but they are often based on OpenSSL. Angus

Currently, the ICS REST component sample does not include file uploading, only building, sending and parsing parameters. There is an old non-SSL sample \WebDemos\ OverbyteIcsHttpPost.dpr that illustrates four different methods for uploading a file using POST, including multi part MIME, which may be tested against the ICS web server samples to receive files. It really needs combing with the OverbyteIcsHttpRestTst.dpr sample for modern use. Angus

ICS V8.68 supports both OpenSSL 1.1.1 and 3.0, you don't need to use an old version. By default it looks for the 3.0 DLLs, then 1.1.1, or GSSLEAY_DLL_IgnoreOld and GSSLEAY_DLL_IgnoreNew control which is loaded. Angus

Done a little more research. SSL Labs tests www.dpma.de okay, but it warns does not support Secure Renegotiation. Using ICS and OpenSSL 3.0.2 I get a different error to depatisnet.dpma.de, 'unsafe legacy renegotiation disabled', but I can connect OK using OpenSSL 1.1.1. There is an OpenSSL issue about this, but it seems OpenSSL is removing support for unsafe negotiations which some older servers try to use. The ICS REST component specifically disables renegotiation, but even enabling it does now allow connection to either web site. So I'm afraid my earlier comment stands, misconfigured web server. Angus

In technical terms, depatisnet.dpma.de is a crap web site! Just run an https://www.ssllabs.com/ test and it says 'Assessment failed: No secure protocols supported' which is very rare, normally poor sites scrape through with a D or E assessment for old protocols. As you say, normal browsers seem to display the page OK, perhaps there is some scripted magic relocation going on or the server does not like our Agent string, but that should only be checked once SSL is negotiated. Rather than using TSslHttpCli, you should start new projects with TSslHttpRest which handles all the SSL and logging for you, look at the OverbyteIcsHttpRestTst.dpr sample. Unfortunately OpenSSL does not provide explanation for protocol errors, they just fail. Angus

The old download page exists, http://vclzip.bizland.com/v4src.htm but all the source downloads are password protected and you can not buy a new license. But maybe someone not using theirs would sell it? I still use VCLZip. Not sure if Kevin is still around, would have been good if it had been made open source. Angus

Ditto, I use Delphi 2007 (and 10.4 and 11.1) on Windows 11. Learnt 10 years ago that I needed a backup of the four NET target files, and have restored them numerous times since after Windows Updates. Sort of related, I also have a workaround that brings the old Windows Help 32 system back to life, as used by Delphi 7 and many other applications from 20 years ago, but which was removed from Windows Vista and later https://www.magsys.co.uk/apps/ Angus