Re: ssl_error(406)

[Brad Stone <bvstone@xxxxxxxxx>]

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