[twsocket] TLS communication issue
Hello Currently I have implemented a TLS client. This application is encountering a communication issue when using a new third party server. I am setting the cert file, private key file, password and ca file. In this configuration the handshake is not performed. Currently I am using ICS v6 with OPENSSL v1.0.0d, but also a version of the client with ICS v8 and v1.0.0j. With both builds of the application the behavior is the same. Using the OPENSSL (v1.0.0d) tool I created a server (openssl s_server command) using the same .pem certificates. With my client I then successfully communicated with this OPENSSL server. Using the OPENSSL (v1.0.0d) tool I created a client call (openssl s_client command) to the third party server and it seems that it was successful. I then proceeded to set the CAPath and now the communication seems to be in place. The only problem is that in this case the server does not encounter/log any successful calls from my side. I also tested the server with a .NET client which uses the same certificate but from windows store and the server logs the activity. Please let me know if you have any pointers/indications that can help me in debugging the communication issue. Thank you in advance. Kind Regards, Marius -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Did I find a bug in THttpCli?
From: twsocket-boun...@elists.org [mailto:twsocket-boun...@elists.org] On Behalf Of Arno Garrels If you just recognized that string property Location doesn't include the port number then that might be a bug. However relocation works without problem for me with the OverbyteIcsWebServ demo listening, for instance, on port 81 and the OverbyteIcsHttpTst demo (your sample URL did not work, please provide an URL that shows the problem). Hi Arno, I think the problem may be more serious. Please try this URL: http://www.htmlvalidator.com/test/cookies/test-redirect.php It should redirect to: http://www.htmlvalidator.com:8080/test/cookies/test-redirect-port.php But THttpCli seems to ignore the port because it uses port 80 when it requests the redirected URL the Location property (in onLocationChange) does not include the port number. If I open the URL in a web browser, then it correctly uses port 8080 for the redirect. Can you help me fix this issue? I need ICS to report (via the Location property) the full URL, including port number, and I need it to use the correct port. Thanks, Albert -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Did I find a bug in THttpCli?
Albert Wiersch wrote: From: twsocket-boun...@elists.org [mailto:twsocket-boun...@elists.org] On Behalf Of Arno Garrels If you just recognized that string property Location doesn't include the port number then that might be a bug. However relocation works without problem for me with the OverbyteIcsWebServ demo listening, for instance, on port 81 and the OverbyteIcsHttpTst demo (your sample URL did not work, please provide an URL that shows the problem). Hi Arno, I think the problem may be more serious. Please try this URL: http://www.htmlvalidator.com/test/cookies/test-redirect.php It should redirect to: http://www.htmlvalidator.com:8080/test/cookies/test-redirect-port.php I tested with current ICSv8/v7 and it works perfectly (checked with Wireshark). The only problem is that property Location doesn't include the non-default port number. A workaround would be to get the Location header manually. But THttpCli seems to ignore the port No it doesn't with a recent ICS, only property Location is a bit buggy IMO. -- Arno -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Did I find a bug in THttpCli?
I tested with current ICSv8/v7 and it works perfectly (checked with Wireshark). The only problem is that property Location doesn't include the non-default port number. A workaround would be to get the Location header manually. In a browser I get an html that says: Server port is 8080. With ICSv8 OverbyteIcsHttpTst I get an html that says: Server port is 80. So something is working differently. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] deflate for OverbyteIcsHttpCCodZLib
Scrive brian - hikarito...@gmail.com: This seems to be finally fixed in the latest Daily/SVN, the data received is transparently uncompressed etc. HOWEVER, there is a small issue, which isn't readily apparent unless you check received data size etc: If you don't include OverbyteIcsHttpCCodZLib anywhere in your app, it won't be used at all even if you add content encoding in the httpcli object options, so the getcoding/complete calls use the default in OverbyteIcsHttpContCod instead and gzip isn't really used. It should be so by design (at least at time I wrote it). But it must be enough to include it one time. Bye, Maurizio. This mail has been sent using Alpikom webmail system http://www.alpikom.it -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Did I find a bug in THttpCli?
Yes, something is wrong. I also just compiled v8 and the OverbyteIcsHttpTst demo as well. If you GET this URL: http://www.htmlvalidator.com/test/cookies/test-redirect.php Then you get Server port is 80. with the ICS demo, but put the same URL in a browser and you get Server port is 8080., so ICS is not handling the port change correctly, nor is it indicating the port in the Location property. I've been using ICS for a while and this never came up until someone using non-standard ports redirection on their development server reported this issue. I'd really like a fix for this. I'm not sure who I should contact about getting this resolved in the code base? Thanks, Albert Wiersch -Original Message- From: twsocket-boun...@elists.org [mailto:twsocket-boun...@elists.org] On Behalf Of RTT Sent: Monday, December 10, 2012 10:40 AM To: ICS support mailing Subject: Re: [twsocket] Did I find a bug in THttpCli? I tested with current ICSv8/v7 and it works perfectly (checked with Wireshark). The only problem is that property Location doesn't include the non-default port number. A workaround would be to get the Location header manually. In a browser I get an html that says: Server port is 8080. With ICSv8 OverbyteIcsHttpTst I get an html that says: Server port is 80. So something is working differently. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] deflate for OverbyteIcsHttpCCodZLib
Yes, including it in the project source is enough, but maybe this should be clearly noted somewhere for other devs, as by default you'd think just setting the Options should be enough. On Mon, Dec 10, 2012 at 7:48 PM, Maurizio Lotauro lotauro.mauri...@dnet.itwrote: Scrive brian - hikarito...@gmail.com: This seems to be finally fixed in the latest Daily/SVN, the data received is transparently uncompressed etc. HOWEVER, there is a small issue, which isn't readily apparent unless you check received data size etc: If you don't include OverbyteIcsHttpCCodZLib anywhere in your app, it won't be used at all even if you add content encoding in the httpcli object options, so the getcoding/complete calls use the default in OverbyteIcsHttpContCod instead and gzip isn't really used. It should be so by design (at least at time I wrote it). But it must be enough to include it one time. Bye, Maurizio. This mail has been sent using Alpikom webmail system http://www.alpikom.it -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] exception after THttpCli.ReqDone causes double triggerof RequestDone
I see. Thanks for the explanation and the workaround :) On Mon, Dec 10, 2012 at 7:17 AM, Arno Garrels arno.garr...@gmx.de wrote: brian - wrote: After RequestDone with THttpCli, if there is an -unhandled- exception before the code is out of ReqDone stack, RequestDone is triggered again. [..] You will see RequestDone is triggered twice, and external exception handlers or delphi's don't trigger at all (e.g madExcept). If you want MadExcept handle those exceptions add i.e. these lines initialization SetIcsThreadLocalFinalBgExceptionHandling(fehAppHandleException); This tells ICS to call the global Application's exception handler for any unhandled background exception in main thread context rather than eat unhandled exceptions. I know I can solve this by using try/except on the final code, or using BgException (canclose := False), Indeed it's best practice to catch and handle all exceptions in the event handlers. but why is this happening? It happens because Abort is called by default on unhandled exceptions which in turn calls OnRequestDone() again. -- Arno -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
