FearDC

It works! Several of SOCKS5 that I tried were faulty. Thank you!

@Angus Robertson I've been testing the SOCKS5 support on TSslHttpCli this morning, which did not work. OverbyteIcsHttpProt.pas has this code: { V8.62 if proxy URL is passed, parse it as proxy properties } { http://[user[:password]@]host:port } if (Length(FProxyURL) > 6) and (Pos (':', Copy(FProxyURL, 6, 9999)) > 5) then begin ParseURL(FProxyURL, Proto, User, Pass, Host, Port, Path); { pending, check https for SSL proxy, maybe socks for socks proxy } if Proto = 'http' then begin FProxy := Host; FProxyPort := Port; FProxyUsername := User; FProxyPassword := Pass; if (FProxyUsername <> '') and (FProxyPassword <> '') then FProxyAuth := httpAuthBasic; end; end; This was the first attempt, but only "http" is supported. Pending means not implemented? The second attempt was setting TSslHttpCli.SocksServer, TSslHttpCli.SocksPort, TSslHttpCli.SocksLevel. Which ended up in HTTP client connecting to SOCKS IP address and port 443 because the TSslHttpCli.URL is a "https://" URL. All this is really messed up. TSslHttpCli.CtrlSocket is being configured correctly but TSslHttpCli bypasses those settings. Am I doing something wrong? Is there a way to trick the HTTP client? Tried searching Google and this forum for solution. I'm on ICS 8.70.

Great, thank you RL.

Thank you everyone. Now sgcIndy website displays correct names, so people can distinguish two different projects and stop thinking that Indy has become a commercial project, because it's not. Also I wonder if any of Indy or sgcIndy have fixed the SOCKS4 response issue. SendV4Response returns LResponse[0] := 4 - which is wrong according to > https://en.wikipedia.org/wiki/SOCKS#SOCKS4 - it should be null/zero instead. Aswell as Sendv4Response(AContext, 90) is faulty in HandleConnectV4. @Remy Lebeau I was going to commit this fix a couple of years ago, but did not remember to do so.

Nevermind about ICSHosts right now, it's not what I currently want, I known that it works only with different ports. If I will get interested in ICSHosts, I will create another thread about it. Now back to SSLEnable option. I managed to set it to False at runtime on DataAvailable callback, and actually got both SSL and non-SSL connection working on same port. Now only need to find a way to detect those bytes and set SSLEnable eccordingly. To be continued...

I did not setup ICSHosts using INI, i did set them up using Object Inspector.

That's what I wanted to hear, that this is possible. This could be a great challenge for me, and a good solution for those many people asking for SSL and non-SSL on the same port. In fact whole this idea started from ICSHosts collection - your latest invention to multi-listening socket. I did specify a SSL and non-SSL port just to test this, but my server application doesn't listen on both ports, instead it listens on just a single SSL-enabled port 1412 - the non-SSL port 1411 is completely omitted. I could find this piece of code: This basically means that setting up both SSL and non-SSL, still different ports, using ICSHosts, is not possible. Is this a bug?

@Angus Robertson I'm not using a HTTP server, this is completely different type of protocol. Lets imagine that a SSL-enabled client connects to a SSL-enabled TSSLWSocketServer, he sends the client hello part of SSL handshake - in order to recognize/use this data we still need to read the bytes from client socket, right? Then once we have read these very first bytes, we actually check two first bytes - once they are magic (means SSL/TLS handshake) we keep shaking hands with the client as in SSL handshake, while if these bytes are not magic, we could just passthrough the SSL handshake and go directly to the TCP data exchange and keep this data exchange SSL-less all the way, as if SSLEnable was set to False for this particular client only. Do you understand what I mean? I'm not talking futuristic ideas right now, this has been implemented in a real software, which allows SSL-enabled and non-SSL clients to use same TCP port in same application > https://github.com/direct-connect/go-dcpp/blob/master/hub/hub.go#L506 . In this example, server application detects those magic bytes and configures the client socket to work either in SSL or non-SSL mode all the way. Ofcourse I understand that not all developers who work with TSSLWSocketServer would like this to be automated, because maybe the protocols they are working with, do actually send same type of magic bytes as part of the protocol. So this option should ofcourse be optional and disabled by default, so their projects don't get broken.