Angus Robertson

These memory leaks are now fixed in SVN, will be zipped overnight, thanks again. 

Angus

In TWSocket, most errors are reported to event handlers, where 0 means no error. 

OnSocksError should only relate to proxies, so you don't need that.  onBgException is for errors for which there no event handler involved, background message handling, etc. If  OnError is assigned, it stops an exception being raised for some errors,  like send data failing, so you need to check function return codes carefully.

Angus

You can also check if a new client connection is from the same IP address as an existing client and use that to close the stale connection.  TWSocketClient has a property CPeerAddr you can read.

Angus

The best solution is for your clients to regularly send something to the server, easy if you write the client code, then you use the last data received tick on TWSocketClient to timeout the connection and close it.  The HTTP server has such a timeout. 

Second best is for the server to send data to the client regularly and check there is no error after 45 seconds or something, then close.  If sending data upsets the clients, you can try pinging them which is much faster, but only catches network failure rather then the TCP session being lost.

Angus

Thanks, will do the changes next week.  In future, can you please add a patch text attachment, I know from experience that trying to use HTML Unicode for patches in Delphi causes corruption.

Angus

The onDataAvailable event has knowledge of the data being received, unless you set LineMode to true, you just read all data into a buffer and process it later.  If binary data is not received, that is an application error. 

Angus

If the database uses stored procedures to isolate the business functions from underlying data and verify input, data, then having the REST API match the SPs would save a lot of coding,  But since most real databases are relationship based with multiple tables,  you don't really want that functionality in browser Javascript. 

Angus

So almost the same as my ComCap application, which works fine without threads, except for adding the captured data to a SQL database which is queued then added in a thread.  Read my previous message again.

Angus

Quote

A proxy, plain simple one, can be used/extended to build  

I looked at ICS demos and don't see one

Not sure what this has to do with this thread.

Suggest you look at the OverbyteIcsProxySslServer.dpr sample.  The ICS proxy component can be used as a forward or reverse proxy with logging.

Angus

I have a commercial ICS application called ComCap with multiple clients accepting data from SSL servers and forwarding that data to other SSL servers, all without threads, it has retries for lost connections.  It makes heavy use of the TIcsIpStrmLog component which runs as a client or server, and has been tested with over 1,000 simultaneous sessions, no threads, no exceptions.

Suggest you look at the OverbyteIcsIpStmLogTst sample and see if you can simplify your application by using TIcsIpStrmLog to replace your TWSocket and TWSocketServers compoents.

Angus

Just build the OverbyteIcsProxySslServer sample,  and edit the INI file to point to the correct SMTP server. 

Angus

You can use a stand-alone proxy server such as STunnel running on the same network to accept connections on port 25 and send SSL to port 465, you don;t need a full SMTP server. 

ICS has a proxy sever component that does exactly that (I use it for an old email client) but we only support Delphi 7 and later.  And using ICS, you'd now use TMailQueue instead of an SMTP client since it queues mail to multiple SMTP servers. 

Angus

The 401 response is expected for Digest and NTLM, there is a challenge returned, you can never avoid it.  The only issue is if you only need to accept it once.

Angus

Probably not the answer you want, but the ICS library has a component TIcsMailQueue which sends emails from a directory of EML files (not MSG), using multiple SSL SMTP servers and retrying until sent.  But it only parses the EML files sufficiently for the SMTP protocol.  There are other components for reading mail headers and bodies.

Angus

Quote

Authorization: Digest username="root",realm="AXIS_WS_ACCC8EE4F05C",

The component is auto selecting httpAuthDigest for which it requires the challenge sent in the 401 response, the component does not have any way of storing the relaam, nonce and other stuff. 

Not sure if the same Authorization: header can be used more than once for subsequent requests, never used Digest myself. 

You'll need to check Wireshark on the other application to find out where it finds realm, etc, or if it uses a different authentication mechanism.

Angus

You should not need to use tools like Wireshark to debug your application, you should add logging into your applications using the onCommand event for data sent and onHeaderData for responses received, this is illustrated in various samples. 

Or use the THttpRest component instead which already has this logging.  You should try your URL in the OverbyteIcsHttpRestTst sample and see what happens.

Long time since I look at basic authentication which is what you are using, but setting ServerAuth to httpAuthBasic should send the Authorization: Basic xxx header with the initial request, which you can check with your logging.

Angus

Unless you are processing data at very high speeds or using a very slow platform, which is unlikely with a COM port, a loop is the ideal simple solution to your problem. Just process one character at a time. 

Angus

Quote

I don't believe there is any possibility of OpenSSL accessing certificates and private keys in the Windows store. 

I was wrong about this, OpenSSL 1.0.2 included an engine capi.dll which allowed access to private keys in the Windows store and dongles, but not their certificates.  It is not currently built for OpenSSL 1,1,1 but may work.  There are periodic questions in the OpenSSL mailing list about CAPI, but the original author of the engine is no longer updating it, and CAPI has been replaced by CNG by Microsoft.  So there is little evidence the CAPI engine still works.

Angus

URL encoding for GET and POST is the same,  although POST may accept Json or XML instead. 

Don't like + for space, should always be %20. The + originates from browser form fields with application/x-www-form-urlencoded MIME POST content, and should not be used in URLs or parameters.

Angus

THttpCli does not encode any parameters, you added that coding, so if the URL does not work you need to correct your code as I suggested yesterday.

Angus

The server has decided it does not like your parameter encoding, but you don't say you how you do it.   Generally, you encode to UTF8 first, then use IcsUrlEncode for each parameter, then combine the parameters.  But there are variations on URL encoding, the latest beta has a new strict parameter for Twitter which is very fussy. 

The better way is to change your application to use TSslHttpRest component, which has RestParams that do all this stuff for you, mostly correctly.  . But update to at least V8.64 first, or even the overnight zip, there have been a lot of changes this year. 

Angus

I've made TriggerSendData virtual in wsocket, most other triggers are already virtual but guess no other component needed to override until now. The change will be in the overnight zip later this week.

Angus

THttpsGetFile was probably one of the many Usermade components written 20 years ago and not touched since.  But he now has a modern version. TIcsHttpMulti.

Angus

As I said, it may use ICS components, but is not part of the ICS distribution.  Need to see the source code to know who wrote it and how.

For simple file downloads build the OverbyteIcsXferTst.dpr sample and try HTTP Downloads.

Angus

THttpsGetFile is not an ICS component.  It may be derived from an ICS component, but you need to ask whoever wrote it.

Angus