GETURI returns the data in 2-3 seconds (similar to POSTMAN). The JSON file is 984 KB right now.

I changed the GUSSLDA20 data area to *IBM and GETURI fails. The joblog says:
Error performing SSL handshake. PeerCertRC(0) RC(-16) errno(0)

Does that information help at all?

-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of Brad Stone
Sent: Thursday, April 15, 2021 4:13 PM
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: ssl_error(406)

How long does it take GETURI to get the complete response? under or over
30 seconds?

What is the buffer size HTTPAPI uses (probably a question for Scott) for
each read?

I know with GETURI you can set things up yourself and I think the default
buffer size is 1024 bytes.

I am just thinking out loud thinking that maybe GETURI's smaller buffer
size keeps the server (or maybe even the client side socket?) awake handing
off data piece by piece vs 1 huge chunk that may take more than 30 seconds?

Probably way off, but it really doesn't make sense since I'm pretty sure we
are using the same GSKit APIs.

GETURI also has a data area named GUSSL02DA that holds the SSL method to
use (IBM vs GSKit). If you change this to *IBM does GETURI still work?
The value should be *GSKIT from the factory (me lol). Any other value will
force it to use the IBM SSL APIs.

On Thu, Apr 15, 2021 at 2:54 PM Greg Wilburn <
gwilburn@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

So the HTTPAPI error message is a bit different now on our new Power9.
I can still use GETURI to GET the JSON payload from the web service. But
the same web service doesn't return the JSON payload to HTTPAPI.

Instead of the 406 error, the http_debug.txt log contains this at the
bottom:

recvresp(): entered
SetError() #44: CommTCP_read: Socket has been shut down.
recvresp(): end with err
http_close(): entered

I had communications traces running during the attempt... IBM Support
reviewed the traces - this was their response:

In QSYSPRT_GWILBURN_TRCCNN_064467_2.txt, we see:
Send at TIME 04/14/21 14:58:14.224436
GET /v1/orders HTTP/1.1 Host: api.meetribbon.com User-Agent:
http-api/1.43
Last entry in this file is 14:58:30.

In QSYSPRT_GWILBURN_TRCCNN_064466_2.txt we see:
at 14:58:14 DNS response for api.meetribbon.com
Then SYN, SYN/ACK, ACK to open a connection.
Src Addr: 192.168.1.254 Dest Addr: 52.85.91.15 Src Port: 41684 Dest Port:
443
Data goes back and forth, then at 14:58:14.262708 the server appears to
ACK request data from the client, but does not send any response data.
At 14:58:44.138036 the server send a RST. Looks like the server popped a
~30 second timer.
There is no indication that I can see as to why the server was unable to
respond to the request data.

Baffling.


-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of
Scott Klement
Sent: Friday, April 09, 2021 2:28 PM
To: rpg400-l@xxxxxxxxxxxxxxxxxx
Subject: Re: ssl_error(406)

Greg,

Previously, you were getting a connection reset prior to it being able to
negotiate certificates. Has that changed?

I don't know anything about this method you are using to verify the
certificate... But, typically when you verify a certificate you need the
whole chain, not just one cert. Do you have the rest of the chain loaded
into the verify tool already?

I'm a little worried about "going down the rabbit hole" trying to verify
certificates... is there a genuine reason to believe that there is
something wrong with the server's certificate?

-SK


On 4/8/2021 3:45 PM, Greg Wilburn wrote:
Still looking at this...

Not sure if this means anything, but the debug test shows a dump of the
local-side certificate. I didn't see that in other httpapi debug files I
have on our system. The certificate string in http_debug.txt looked "too
short" to me.

So I copied the certificate string, saved it on my PC as a .cer file
and opened it. Under Certificate Information it says "Windows does not
have enough information to verify this certificate."

Grasping at straws here.

--
This is the RPG programming on IBM i (RPG400-L) mailing list To post a
message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
--
This is the RPG programming on IBM i (RPG400-L) mailing list To post a
message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.