Fr0sT.Brutal

HTTP Tunnel and Socks server addresses can not have literal address (including 'localhost') because IPv6 check in `procedure TCustom*WSocket.Connect` throws 'Unsupported address format'. I suppose this check should only test for unavailable IPv6 case (i.e. address is IPv6 but OS doesn't support it).

Angus, I use the fresh trunk from SVN. In most cases, enclosing all unit contents in IFDEF will help (just like OverbyteIcsLIBEAY f.ex.)

And #4 happens with SSL, maybe your Delphi allows this? Mine XE2 refuses to override non-virtual methods (and it is obviously right)

I have latest SVN version.

First of all, `USE_SSL` is uncommented by default in defs.inc so a user has to edit defs file otherwise he can't control this option.

Second, without `USE_SSL` ICS packages couldn't be built as following units have incorrect defines sections:
 

  OverbyteIcsSslX509Utils in '..\Source\OverbyteIcsSslX509Utils.pas',
  OverbyteIcsLibeayEx in '..\Source\OverbyteIcsLibeayEx.pas',
  OverbyteIcsProxy in '..\Source\OverbyteIcsProxy.pas',
  OverbyteIcsSslJose in '..\Source\OverbyteIcsSslJose.pas',
  OverbyteIcsSslHttpRest in '..\Source\OverbyteIcsSslHttpRest.pas',
  OverbyteIcsSslX509Certs in '..\Source\OverbyteIcsSslX509Certs.pas',
  OverbyteIcsIpStreamLog in '..\Source\OverbyteIcsIpStreamLog.pas',
  OverbyteIcsMailQueue in '..\Source\OverbyteIcsMailQueue.pas',
  OverbyteIcsHttpMulti in '..\Source\OverbyteIcsHttpMulti.pas',
  OverbyteIcsFtpMulti in '..\Source\OverbyteIcsFtpMulti.pas',

Third, unit `OverbyteIcsHttpAppServer` can't be built as well as it uses `ClientCnx.HostTag` that is unavailable without SSL

Fourth, `TSslWSocketClient` has `TriggerSslAlpnSelect` overridden method that is not virtual in base `TWSocketClient` so compiler produces build failure.

Francois, of course this will do the trick but this means client code must meet some requirements which doesn't seem reliable to me.

Angus, well, have exceptions raised and shown could sound bad but it's really much better than have them swallowed silently IMHO. Unawareness of errors could cause mysterious AVs and other non-relative errors in random places. And all systems that claim to be robust should have bg exceptions handler already ¯\_(ツ)_/¯

Hi all,

spent some time just now on investigating a weird bug, it happened to be a memory AV that wasn't reported or caught by my exception handlers. Finally I came to see TCustomWSocket.ASyncReceive which appeared to just silently swallow any exceptions that happen in TriggerDataAvailable. I suppose it should have HandleBackGroundException(E) shouldn't it?

Ver.: 8.58

File: OverbyteIcsWSocket.pas

Line: 8427