HTTPClient_services send request timing out

AusMarkB

I'm hoping for some suggestions as to why a request may time out.
I understand the process from this end, loop for a period checking readystate.
I have resurrected some code from a couple of years ago that sends requests to update external dashboards. It keeps timing out as readystate is always set to loading. I'm looking for hints as to why that may be.

Initially I thought the endpoints may have changed but then I copied the code and data locally and voila worked a charm whereas it constantly timed out on the client server. To me that suggests something environmental but I have no idea where to start looking. It used to work on the same server as that's the only place I've ever used it but it's been laying dormant for 18 months or so and the IT department do like to change things up from time to time.
I just don't know where to send them looking.

So, if you send a request and readystate comes back as 'loading', or 1, what does that really mean?

DonBakke

It actually means what it says. What you are describing sounds quite similar to what we've been hearing about from others in the Revelation forum by those trying to use OLE_GetWebPage. After consulting on a couple of these situations I've discovered that some servers, especially if they require certs, are not responding to Server XMLHTTP requests. The answer is to switch the to Client XMLHTTP, which you can specify with the SendHTTPRequest service via the UseXMLHTTP flag. Try that first and see if it gives you more reliable behavior.

AusMarkB

I was getting a little excited, thinking you had given me the simple magic solution and indeed at first glance it seemed like you had.
Now, readystate comes back completed.
However.... response still comes back null which is effectively the same as before. It says it's completed but nothing has really happened.

DonBakke

Despite the lack of a response, this is actually progress. It suggests to me that the server processed the request and responded, albeit it seemed to return nothing. Just out of curiosity, did you confirm that the response status was set to something valid, like 200? What about response headers? Anything there?

Do you have a way to confirm if the dashboards are even seeing the request? Are these your dashboards or a 3rd party's? I presume if you send a request to the dashboards using another client, like Postman, you get a good response?

AusMarkB

The response status was set to null, so nothing valid. No response headers.
The dashboards are a third party - Geckoboard.
As per your suggestion, I installed postman on the server and ran it from there. All good. Appropriate response and the dashboards updated.

So I debugged again and stepped deeper into httpClient_services. All the individual calls in there were consistent with the overall result. No errors identified but no response.

…. except for one
After you send the request and error_services finds noError then this happens
Code = SRP_COM(objXMLHTTP, 'GET', 'status')
Code gets set to 12029
The next line looking for statusText comes up null so the 12029 is the only thing to go on.

So in summary.
Send from OI on local laptop and network - all good
Send from Postman on local laptop and network - all good
Send from Postman on client server and network - all good
Send from OI on client server and network - nothing happens; get a 12029 if you look hard enough.

DonBakke

At least this gives us a meaningful reason for the lack of a response. If the COM object encounters an error, then the HTTP request/response is not going to work as expected. I did a quick search and I'm certain the problem is similar to what this Microsoft article is referring to.

It's important to remember that the XMLHTTP object (client or server) is still a Microsoft Explorer object and is governed by the Internet Explorer Settings. I am hopeful that herein lies the solution to your connectivity problems.

AusMarkB

Thanks for the link. I had found other similar ones and pursued the same sorts of things to no avail. I was also a little reluctant to modify too many security based settings as that would be outside of our domain.
However, I came onsite today and was just gathering some info to pass onto the IT guys that are responsible for that sort of thing and was reminded that they're moving to a new server.
I got access to the new server, ran the same code and voila, everything is as it should be.

The world is now a better place again and the mysterious 12029 can go ponder its actions in the wasteland that houses retired servers, hopefully never to be heard of again.

DonBakke

I love it when problems fix themselves...other than leaving behind an somewhat unresolved mystery.

By "new server", did you mean a new server that is running OI or a new web server? If the former, what was the OS of the old and new server?

AusMarkB

Former.

Old - 2012
New - 2016

AusMarkB

This has cropped up for me again but with a different use case.
We're rolling out some work utilising the sendHttpRequest service and whilst everything worked in testing, once we hit some clients, it worked for some and not for others.
The solution for those that didn't work was to do as you originally suggested here Don and set the useXmlHttp flag so that the client object is used instead of the server object.

What's the likelihood that if I switch to the client object, that some of those that worked with the server object will subsequently fail and I'll be back to a works for some not for others scenario?

The function is both POSTing and GETting requests. For the GET request, I've added the 'If=Modified-Since' header as recommended in your blog post on this topic so as to prevent caching. On that, I've read and reread the blog post and I'm still not entirely sure as to whether there are any genuine risks with using the client object though the blog seems to recommend the server and your services default to it so I feel like that should be the preference.

DonBakke

What's the likelihood that if I switch to the client object, that some of those that worked with the server object will subsequently fail and I'll be back to a works for some not for others scenario?

No way to answer that. This is so environmentally dependent that no one can predict if and when the environment will change.

AusMarkB

I might make it a control flag somewhere that can be implemented as needed on a per client basis