oHttp := CHttp{"Secure_Rates", INTERNET_DEFAULT_HTTPS_PORT }
//
IF oHttp:ConnectRemote( WEBSERVER_2016 ) // "27.50.65.xxx"
// Do stuff.

Randomly at first this will return false.. same box the IP.
Can ping to the IP.. it is there.
Some other flags to pass or some other way to test.

When I try and process again the connection continues to fail until I stop and start my VO service.

Any ideas... things to try...

Phil McGuinness

can you set a timeout in your connectremote ?

Massimo Bighelli
ARCA Sistemi S.r.l.

Il 21/09/2021 03:07, Sherlock ha scritto:
> oHttp := CHttp{"Secure_Rates", INTERNET_DEFAULT_HTTPS_PORT }
> //
> IF oHttp:ConnectRemote( WEBSERVER_2016 ) // "27.50.65.xxx"
> // Do stuff.
>
> Randomly at first this will return false.. same box the IP.
> Can ping to the IP.. it is there.
> Some other flags to pass or some other way to test.
>
> When I try and process again the connection continues to fail until I stop and start my VO service.
>
> Any ideas... things to try...
>
> Phil McGuinness
>

Massimo

no Timeout in this class.

oHttp := CHttp{"Secure_Rates", INTERNET_DEFAULT_HTTPS_PORT }

oHttp:Timeout := 6000 // Syntax like this not part of class

//
IF oHttp:ConnectRemote( WEBSERVER_2016 ) // "27.50.65.xxx"
// Do stuff

Based VO cHTTP class issue solved with a move to winHTTP
I call this code and a lot of it via a VO app running as service for like 15 years.
No reliable now and random.
The service has to be stopped and started and wait for the random inability to ConnectRemote()

interesting a Socket call prior to same port etc... works.
The cHTTP connect fails.

Phil McGuinness
----

> oHttp := CHttp{"Secure_Rates", INTERNET_DEFAULT_HTTPS_PORT }
> oHttp:Timeout := 6000 // Syntax like this not part of class
> //
> IF oHttp:ConnectRemote( WEBSERVER_2016 ) // "27.50.65.xxx"
> // Do stuff

Hi Phil,

the VO cHTTP class is based on WinInet - this is practically the
communication layer of the Internet Explorer.

It could be that now that Internet Explorer is being dismissed also the
WinInet library has some not fixed problems.

Wolfgang

Phil McGuinness wrote:

> Based VO cHTTP class issue solved with a move to winHTTP
> I call this code and a lot of it via a VO app running as service for
> like 15 years. No reliable now and random.
> The service has to be stopped and started and wait for the random
> inability to ConnectRemote()
>
> interesting a Socket call prior to same port etc... works.
> The cHTTP connect fails.
>
> Phil McGuinness
> ----
>
> > oHttp := CHttp{"Secure_Rates", INTERNET_DEFAULT_HTTPS_PORT }
> > oHttp:Timeout := 6000 // Syntax like this not part of class
> > //
> > IF oHttp:ConnectRemote( WEBSERVER_2016 ) // "27.50.65.xxx"
> > // Do stuff

--

snip[ the VO cHTTP class is based on WinInet - this is practically the communication layer of the Internet Explorer. It could be that now that Internet Explorer is being dismissed also the
WinInet library has some not fixed problems. Wolfgang ]

I suspect app running as service has a throttle limit if exceeded the connect via cHTTP is deactivated for the session the service is running.
Restart all good until some threshhold reached again. Sure with Internet Explorer. It only fails as service. For all other works fine, so far.

Re winHTTP in most places in my Service replaced cHTTP and working great. First time in a month this random issue.
Another part bit more complex but day or so will be replaced. I can still see it fails on cHTTP but my most critical does not anymore.
Will release a Function you can use for most anything for those do not want to learn the inner workings.
I have a HttpCall() function a wrapper and will release winHttpCall().

Simple to drive, black box for those that just want something that works.

Phil McGuinnness

Hi Phil,

the main issue why I wrote the winHttp class is that WinInet is not
supported in Windows services, and I needed that:

https://docs.microsoft.com/en-us/troubleshoot/browsers/wininet-not-suppo
rted-in-services

Wolfgang

Phil McGuinness wrote:

> snip[ the VO cHTTP class is based on WinInet - this is practically
> the communication layer of the Internet Explorer. It could be that
> now that Internet Explorer is being dismissed also the WinInet
> library has some not fixed problems. Wolfgang ]
>
> I suspect app running as service has a throttle limit if exceeded
> the connect via cHTTP is deactivated for the session the service is
> running. Restart all good until some threshhold reached again. Sure
> with Internet Explorer. It only fails as service. For all other
> works fine, so far.
>
> Re winHTTP in most places in my Service replaced cHTTP and working
> great. First time in a month this random issue. Another part bit
> more complex but day or so will be replaced. I can still see it fails
> on cHTTP but my most critical does not anymore. Will release a
> Function you can use for most anything for those do not want to learn
> the inner workings. I have a HttpCall() function a wrapper and will
> release winHttpCall().
>
> Simple to drive, black box for those that just want something that
> works.
>
> Phil McGuinnness
>

--

Wolfgang Riedmann

snip[ the main issue why I wrote the winHttp class is that WinInet is not > supported in Windows services, and I needed that: ]

Bugger it did for 15+ years.......... but a way forward. Your class a bit more, samples and good tutorial site for programmers.

http://www.sherlock.com.au/sherlock32/Test_winHTTPCall.zip

Hope others get good use out of this code.. we used it extensively. use the class use the function, it all works.
Phil McGuinness

Hi Phil,

> snip[ the main issue why I wrote the winHttp class is that WinInet is
> not > supported in Windows services, and I needed that: ]
>
> Bugger it did for 15+ years.......... but a way forward.

I had used it too, but since I had some strange issues I have
researched and found that link. Since I have changed the services no
more issues.

And in most GUI applications I have also started to use winHttp.

Wolfgang

--