HTTPAPI uses the operating system's implementation of SSL when a URL
begins with https: (which indicates to use SSL.)
It has nothing whatsoever to do with XML. Just SSL.
As to whether it's required, this depends entirely on the web service or
HTTP server that you are connecting to. Does the web service require
you to use SSL? Then it's required for HTTPAPI...
On 3/12/2014 3:26 PM, Thomas Garvey wrote:
I am trying to set up a software vendor's product, which incorporates
and uses Scott Klement's HTTPAPI Service program, on a v5r1 system.
It's using HTTPAPI to prepare and send XML docs and consume a web service.
However, in doing so, HTTPAPI apparently needs to use the Digital
Certificate Management facilities of the OS. On v5r4 this is no problem
as DCM is part of the OS.
On v5r1 it is a separate OS option (34). So, we installed that
option. However, it also somehow needs 5722-AC3 (Crypto Access provider
128 bit), which was rolled into the base OS on v5r4
but is a separately ordered and licensed product back on v5r1. The
client doesn't have the 5722-AC3 on its install CD's and they have no
way of getting it, as far as I know.
Without 5722-AC3 we can't set up the Certificate Store on the v5r1 box.
(It says it needs 5722-AC3 installed).
It occurred to me that I could comment out the DC requests and see if
the HTTPAPI would still work (in other words, make the API not attempot
to use DC's).
I inquired of the vendor what would happen on the web service end if I
did this and they don't know.
Apparently, we both have levels of ignorance about Digital Certificates.
So, I guess I'm asking if anyone has tried this and whether I am barking
up an empty tree (maybe DC is an integral part of XML conversations with
Can anyone direct me what procedure calls in HTTPAPI can/need to be
BTW, the software vendor only supports their application from v5r4 but
agreed to let us try to retro it to v5r1 for a mutual client.
Thanks for any advice, and be gentle with me, acknowledging my ignorance
of what I speak.