Re: New SQL HTTP_POST question

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.