Angus Robertson

The OnClientConnect event I've mentioned twice is how you know the client is connected. TSslWSocketClient is not created until after connection is successful, although SSL negotiation may still fail so the socket gets disconnected again. Servers only ever listen and respond to commands from remote clients, most clients will cleanly disconnect once completed, but you generally don't know if the client is still there which is why most servers have a timeout for an idle client. Angus

Again why does it matter? The client has already connected to the server by the time the client socket is created and the OnClientConnect event has been triggered. SocketState is only used by the component to check if the socket needs to closed, there is no connecting state concept for a server listening socket. Angus

Why does any of this matter, this is a listening server and there is no thread until after a client connects successfully, which you see from the OnClientConnect event. The server state should always be wsListening. BTW, TSslWSocketThrdServer has now been updated or tested for many years, although it descends from TWSocketServer which is heavily used and updated. Angus

Nothing to do with any file name, more likely a new bug in Hyper-V on Windows 10, at least never seen it before. After accessing a couple of virtual machines (with old compilers), discovered Hyper-V has installed 57 Virtual Ethernet Adaptors, for no obvious reason, not seen that before. Uninstalled 50 adaptors, one at a time, and Delphi runs again. Angus

SSL clients don't need certificates. Are the DLLs in the same directory as the application, if not you may be opened rubbish from elsewhere on the PC. And try other samples, to see if just one failing, specifically try OverbyteIcsXferTst.dp which is a far more advanced FTP client with better error handling. Angus

Very unusual to see access violations with OpenSSL, most likely mismatched DLLs or a very old version of ICS and a newer OpenSSL. Certainly nothing wrong with the components, use SSL all the time. What about other ICS SSL samples, so they all fail as well? Angus

I know the function works because it unpacks and logs real ALPN data, but for completeness I've added logging of the ALPN wire packet: AlpnCB> inlen: 12 - 02683208687474702F312E31 AlpnCB> Protocols: h2,http/1.1 I also know the ALPN data may be incorrectly formed, OpenSSL simply passes whatever is received in the TLS initial packet, because until I fixed the bug yesterday, Delphi unicode compilers where sending 086008700470047 for http/1.1 if ALPN was specified in SslContext (not the default). This was correctly ignored by the ICS web server, but I noticed it because one of my web pages reports the client ALPN and was truncated by the first null. I would eventually have found this when testing the Let's Encrypt TLS challenge which does not work yet due to another OpenSSL callback bug. Angus

Don't believe there a problem in IcsWireFmtToStrList, more likely to be setting the output pointer for the AlpnSelectCallBack function, which means OpenSSL reads a Delphi variable. Originally it was a local variable but it had gone out of scope when OpenSSL tried to read it. so V8.62 changed it to a TWSocket variable FAlpnProtoAnsi and that worked for Win32, and for Win64 according to my testing here. But perhaps there is something different about your server implementation to the ICS samples, As I said before, simply not using the onSslAlpnSelect should have fixed the issue. Angus

I've updated the ICS OverbyteIcsSslMultiWebServ sample with the code you show (which comes from the older web server sample), built and tested it for Win64, and it's working fine, no exceptions with ALPN which is being reported correctly, using OpenSSL 1.1.1d Win64. The code you show for the onSslAlpnSelect is correct usage, but not really needed since applications should default to HTTP/1.1 anyway unless told to use HTTP/2. I did fix a memory bug in V8.62 relating to this which I guess could have come back or not been fixed properly. I would just comment out the loop so the event returns without changing ErrCode and see if your problem goes away. I have updated the wsocket ALPN code to suppress any exceptions processing ALPN since it's not really fatal and made IcsWireFmtToStrList check for bad packet formatting. More importantly, during testing I found a unicode bug in IcsStrListToWireFmt which is used in HTTPS clients sending the ALPN list which sent a corrupted packet, now fixed, but you are not using that since we do not send the h2 protocol. I'll put the source changes in SVN once my own public web server has been updated and been used for at least 24 hours. Angus

In which component are you seeing the access violation, IcsStrListToWireFmt should only be called in SSL servers. Angus

Don 't do much testing with Win64, unusual to find problems, particularly with a simple loop. But that function is only used in one place in ICS, to decode the ALPN response during an SSL handshake, so the buffer is within the OpenSSL DLL, maybe there is an issue with the buffer alignment or something? No ICS applications currently use the ALPN response, so I'll hide the exception as a quick solution. Is this problem with all SSL web sites or just one in particular, which is perhaps returning invalid data in the SSL handshake? A typical ALPN response is just 'http/1.1, h2' so say that HTTP/2 is supported. Angus

Don't know anything about DEVEXPRESS components, but from reading your comments you purchased an ActiveX component from them which was written in Delphi, but which they no longer support, and you have no source code for it, but do have a similar VCL component with source? Surely the fastest solution is try and buy the ActiveX source from DEVEXPRESS so you can bring it up to date? Perhaps even off to let them sell your new version for others in the same situation. Recreating it 100% accurately is not a trivial task. Windows 10 generally retains compatibility with all earlier technologies, it's rare for Microsoft to obsolete APIs and stuff, but security often gets harder to implements, particularly because ActiveX was a horrible risk in MSIE. I wrote a non-visual COM object 10 years ago with a type library, for use with ASP web pages, which was relatively easy, but a visual grid will be more complex. Angus

Or a less specific topic to cover HTML components from other developers as well, such as https://github.com/BerndGabriel/HtmlViewer Angus

If you use the component in the recommended way as I said earlier, it works fine, and does for many others. There are no plans to change the internals of THttpCli, unless necessary to fix some horrible issue, it's been fine for 20 years. Angus

The ICSLogger is designed for our internal debugging of the components, and needs extra information added to be useful for application level debugging, such as when you start a request, and the events called. It does not log the NTLM requests,. which is where your statuscode is coming from, not the real request. Beware we don't often test NTLM since it so rarely used on the public internet. Angus

Not looked at the code, but generally status=0 means an internal error or something unrelated to the HTTP protocol like SSL or disk I/O, hopefully your application logs all the protocol commands and responses which will help indicate at what point the error happened. If you use TSslHttpRest instead of THttpCli, logging is built-in. I would not rely on the component internal state completely, you should not start a new request until after OnRequestDone has been called, ie post a message from that event that triggers the next request in the queue, Angus

If you set the properties separately, don't use ProxyURL, that override them all. It was add added to avoid needing to save four or five different properties, and pass them up from derived components. Angus

The proxy sample handles non-SSL as well. the four properties Proxy, ProxyPort, ProxyUsername and ProxyPassword are all set by ProxyURL, so don't use them together. Never used ProxyConnection. Angus

ICS includes an HTTP proxy component and sample project which you can build and run locally for testing, OverbyteIcsProxySslServer.dpr. Assuming you are using V8.62 or later, there is a new property ProxyURL property which combines four proxy properties as a URL for simplicity, ie http://[user[:password]@]host:port. You still need to set ProxyAuth if that is needed. A proxy listens on a specific IP address and port, and then forwards traffic to the original URL. For testing, you can set 127.0.0.1 and port 81, and set-up the proxy to listen on the same, so ProxyURL would be http://127.0.0.1:81. Angus

Did you get anywhere using the Google RSA-PSS private key? I've made IcsJoseFindAlg recognise them OK, but then hit a problem in IcsJoseJWKPubKey because the OpenSSL RSA functions don't seem to work on RSA-PSS keys so I can not read the exponents needed, I think this was why I have up testing RSA-PSS 18 months ago hoping OpenSSL would fix this, but not yet. There are possible workarounds. Angus Update: OpenSSL changed the RSA functions to recognise RSA-PSS keys in October, but not had a new release of 1.1.1 since, so we need to be patient and it will work soon.

No, the ICS HTTP server is independent of the Windows http.sys API, While a server running at kernel level is potentially more efficient than one at application level, all the REST and authentication stuff would still be at application level. You are also restricted to server facilities Microsoft chooses to offer, which are present means no TLS/1,3 or modern ciphers, for instance. So really only an advantage for very heavy load servers. Angus

Not much error handling for opening the file, it might not exist or be protected, or whether you read it correctly, I set all the output parameters for PKCS12_parse to nil before calling it, unless this is a very old Delphi your password is not AnsiString, just a few things to try, OpenSSL error handling might give you some ideas. Your last line does not work with any newer versions of OpenSSL, and 1.0.2 is out of support in four weeks. ICS has a TX509 certificate class that does all this for you, including getting all certificate fields, and another that renews it automatically before expiry. You can use these with internet libraries. Angus

ICS is a project developed by volunteers and offered free of charge to the community. Volunteers come and go, and currently there are none helping with C++ and MacOS, so our level of support depends on reports from end users, and we try to react. We spend our time developing for platforms used by the majority of Delphi users, if those on other platforms don't help, they should not expect support. V8.60 earlier this year added a lot of new components and it seems no MacOS user has tried to build this, thus the errors were not found. So download V8.59 or earlier which should be okay for MacOS. The last bug specifically fixed against MacOS was in V8.52. I will fix or workaround GetComputerNameW and GetThreadLocale, etc etc etc does not really help, there are not many new APIs. I really don't have the time spend hours on this stuff, I just need to be told what to fix. Angus

Did you try removing the offending Windows only SystemTime functions? Did ICS then build okay on MacOs64? I've corrected that problem in master, but need to know if other MacOS errors then occur. Angus

It was concept code, how to get the port of an open socket. and can be simplified somewhat to: BindIpPortStr := Socket.GetXPort; since it's a built function that the FTP client seems not to use. In this case Socket is your TSocketServer component, provided you are not using IcsHosts. The IcsHosts implementation up to V8.63 does not allow a zero port, since that means there should be an SSL port specified instead, each IcsHost is designed to listen on two ports at once. But this was a bad design, so I'll change it for the next release so that both ports being zero uses a non-SSL random port. I'll also return the random port allocated, somewhere. Angus