Re: New SQL HTTP_POST question -- MIDRANGE-L

So after reading this entire thread and related links it is still
unclear the syntax to specify a bearer token in the header of an
qsys2.http_post...
Does anyone know?

The following does not work (and a vast variety of combinations of trial
and error did not either... )...

{"headers":{"content-type":"application/json","sslTolerate":true,"Authorization":
"Bearer <token>"}}

in my case, my bearer token is just under 1k

tia

jay

On Wed, Jan 19, 2022 at 7:49 AM Bobby Adams <bobby_adams@xxxxxxx> wrote:

Oh my gosh. Now, that you have pointed out about the comma in the
documentation I have to wonder how I missed it. I know I have read that
dozens of times. I even looked back at the the examples I found on the
internet and the commas were practically jumping off the page at me. I
guess I got tunnel vision after seeing the example on the Pitney Bowes
site.

Thank you for following up on my comments.

Regards,

Bobby

On 1/19/2022 03:40, John Yeung wrote:

On Tue, Jan 18, 2022 at 3:56 PM Bobby Adams <bobby_adams@xxxxxxx> wrote:

OK, I solved it. The problem was in the formatting of the headers. As
you can see below, the headers had a colon after the attribute but
before the value. For example "Authorization: Bearer ....". However,
it should have been a comma instead of a colon.

So you mean when you changed it to "Authorization, Bearer ..." it worked?

That's... interesting.

At least in all cases
except for "ssllTolerate":"true". That had to be a colon.

Maybe it's a very small thing, but this comment seems a little weird
to me. "All cases except for X" implies that X is a member of the set
of "all cases". But the colon between "sslTolerate" and "true" is not
the same kind of thing as the colon in "Authorization: Bearer ...".
The colon between "sslTolerate" and "true" is the same kind of thing
as the colons following "header".

Those colons (following each instance of "header" and the instance of
"sslTolerate") serve to separate names from values in name:value
pairs. They are meaningful JSON syntax.

The colons that you switched to commas are, in this context, just
characters within string values. As far as JSON is concerned, you
could just as well switch them to semicolons, periods, or the letter
'z'.

So, the interesting thing is what the HTTP_POST function is doing with
the JSON passed in that third parameter.

There is a hint in the docs that suggests HTTP_POST is indeed
expecting commas in the spot you are describing. I'll quote it here:

From the description of the "header" option In "Table 1. HTTP options"

found at

https://www.ibm.com/docs/en/i/7.3?topic=functions-http-get#rbafzscahttpget__HTTP_options

<blockquote>
Sets an HTTP header in the HTTP request with the specified headername
and headervalue. This option can be specified multiple times to set
multiple headers.

A common headers[sic] that may be required is the Accept header. This
header can be set in the following way: "header":"Accept,*"
</blockquote>

Until I saw your message, I would have thought the comma in the docs
was a typo. But apparently, the HTTP_* functions are taking those
commas and turning them into colons before passing along the request
to the URL.

I have two reactions to this. First, that seems unnecessarily
convoluted. I have a guess as to why they designed it that way, but I
don't think it was a good idea.

Second, if commas are really required there, I would have expected a
lot of people to have stubbed their toe on this already and be equally
confused as all of us have been in this thread. Surely this behavior
would warrant a lot of questions, comments, and complaints on these
mailing lists and elsewhere. Maybe it has and I just didn't notice?
I'll admit I have not tried finding earlier mentions of this in the
archives.

Anyway, to address this last point:

The examples
at the Pitney Bowes site had colons, although the examples were using
Curl. I'm new to all this so I don't know if it's something peculiar
about SQL or Curl that requires one over the other.

It's definitely a peculiarity about Db2 for IBM i. As far as I'm
aware, no other SQL has these functions, or they are named differently
and (probably) work differently.

John Y.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-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