Yes, my CGI webservice is also a client of 3rd party services.
The HTTPAPI calls are failing. My service program is checking the return value and taking appropriate action. The trouble is that once the HTTPAPI calls begin failing, every subsequent call also fails (last week, there were 360+ failures before ops noticed).
I've been operating under the assumption that something changes with the vendor's cert and my CGI jobs have stale state, which causes the trouble. If that's truly the problem, moving the HTTPAPI calls to a different job wouldn't help (unless you did something like *INLR or RCLACTGRP).
-----Original Message-----
From: Nathan Andelin [mailto:nandelin@xxxxxxxxx]
Sent: Tuesday, September 18, 2018 3:57 PM
To: RPG programming on the IBM i (AS/400 and iSeries) <rpg400-l@xxxxxxxxxxxx>
Subject: Re: HTTPAPI & revoked SSL cert
On Tue, Sep 18, 2018 at 1:37 PM, Bradley Stone <bvstone@xxxxxxxxx> wrote:
Unless there's something left out of the picture here, I'll reiterate
that the Apache server shouldn't have anything to do with HTTPAPI.
Brad,
Justin hasn't really explained it, but he's evidently making HTTPAPI calls from an IBM i CGI program, which itself also responds to HTTP requests. Web applications and web-service servers (CGI programs) can be web-service clients too.
The problem here appears to be that the error in the CGI program destabilizes the HTTP server. So far, the fix is to restart the HTTP server, which is obviously is NOT GOOD.
One way to eliminate the problem would be to make the HTTPAPI calls from a separate job, which communicates with the CGI program via data queues. That would at least keep the HTTP server from becoming destabilized. Ultimately, he needs to add error handling to the program that's making HTTPAPI calls.
Nathan.
midrange.com
