×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
I was given an off-List suggestion to set up something locally, that
would return the same data stream as the web service.
I did this by setting up a "canned" version of the response, as a static
page on a Tomcat server that runs locally (VERY locally: the same box).
And I don't get the malfunction at all.
The only difference is that with the real web service, I'm giving
http_url_get_raw a URL that's well over 100 characters long, while with
the fake web service, I'm giving http_url_get_raw a URL of
'
https://127.0.0.1/test05jl2024'
Further experimentation in a browser told me that I could tack on
parameters to the URL, and it would still return my canned response. So
I put the parameters back in. Still no malfunction.
But it malfunctions with the real web service call.
I'm beginning to wonder if the problem is protracted HTTPS negotiations:
on *our own* web services, I had to open a separate port, restricted to
the office IP address, that would tolerate ciphers that a V6 box could
handle. And I was surprised that the Google geocoding service was
tolerating the V6 box's ciphers. Could this be stretching out the HTTPS
negotiations? Could protracted HTTPS negotiations be what's causing
wonky memory allocations in HTTPAPI?
--
JHHL
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
