scottklement.com

I am trying to post an entry to a GreyLog syslog server.

I can successfully post a log using curl from a strqsh session - see example below.

But when I try using the HTTPAPI Command it fails which I was using for a quick test and perhaps is a limitation of the command ??

This works
The following commands are run before starting qsh
ADDENVVAR ENVVAR(QIBM_QSH_CMD_ESCAPE_MSG) VALUE(Y)
ADDENVVAR ENVVAR(QIBM_MULTI_THREADED) VALUE(Y)
strqsh
/QOpenSys/pkgs/bin/curl -X POST -H 'Content-Type: application/json' -d '{ "version": "1.1", "host": "example.org", "short_message
": "Testing from QSH using Curl", "level": 5, "_some_info": "foo" }' 'http://Bnelog1.isuzu.local:12201/gelf'
$
The $ tells me no error was detected and the entry does appear in the syslog server

But using HTTPAPI Command no entry is received in the syslog server

HTTPAPI URL('http://Bnelog1.xxxxxx.local:12201/gelf') DOWNLOAD('/home/msd/result.txt')
REQTYPE(*POST) UPLOAD('/home/msd/syslog.txt') TYPE('application/json') DEBUG('/home/msd/debug.txt')

13 HTTP/1.1 202 Accepted

The syslog.txt contains
************Beginning of data**************
-d '{ "short_message": "This is a short message", "full_message":"This is th efull message ", "host":"Hostname", "version":"Version
", "timestamp": "1629332852.490", "level": "01" }'
************End of Data********************

The result.txt is empty

The debug.txt contains
************Beginning of data**************
HTTPAPI Ver 1.42 released 2020-10-12
NTLM Ver 1.4.0 released 2014-12-22
OS/400 Ver V7R3M0

New iconv() objects set, PostRem=819. PostLoc=0. ProtRem=819. ProtLoc=0
http_persist_open(): entered
http_long_ParseURL(): entered
DNS resolver retrans: 2
DNS resolver retry : 2
DNS resolver options: x'00000136'
DNS default domain: XXXXX.LOCAL
DNS server found: 192.168.126.2
DNS server found: 192.168.126.3
DNS server found: 10.100.0.210
Nagle's algorithm (TCP_NODELAY) disabled.
http_persist_post(): entered
http_persist_req(POST) entered.
http_long_ParseURL(): entered
http_long_ParseURL(): entered
do_oper(POST): entered
There are 0 cookies in the cache
POST /gelf HTTP/1.1
Host: Bnelog1.xxxxx.local:12201
User-Agent: http-api/1.43
Content-Type: application/json
Content-Length: 182


sendraw(): entered
-d '{ "short_message": "This is a short message", "full_message":"This is th efull message ", "host":"Hostname", "version":"Version", "timestamp": "1629332852.490", "level": "01" }'
recvresp(): entered
HTTP/1.1 202 Accepted
content-length: 0
connection: keep-alive

SetError() #13: HTTP/1.1 202 Accepted
recvresp(): end with 202
recvdoc parms: identity 0
header_load_cookies() entered
recvdoc(): entered
SetError() #0:
recvdoc(): Receiving 0 bytes.
recvdoc(): Nothing to receive, exiting...
SetError() #13: HTTP/1.1 202 Accepted
http_close(): entered
************End of Data********************

Any suggestions appreciated.

As far as I can tell, this is a bug in the command version of HTTPAPI. Until the last few years, it was almost unheard of that a server would return a response code in the 200 range aside from 200 itself. With the increase in REST-based APIs, this has changed a lot and people are using other 2xx codes more often.

Probably nobody has tried it with the command version of HTTPAPI before.

I'll take a look and see what I can do.

I was only using the command to test and once working I was going to add it to a RPG program.

So you are suggesting it is a problem with the command - I hope that is the case as I have tried many slight alterations with all returning the same message.

I will write the rpg option and advise an update.

Thank you for looking at this.

Please try downloading version 1.45 from http://www.scottklement.com/httpapi/ -- this is a new version that should fix the problem with the HTTPAPI command. (The command simply didn't know about other 2xx responses besides 200. This is no longer the case.)

Thank you - I will and will advise how it goes.

I have downloaded and installed version 1.45
I have run the same test and no error is displayed.
In the debug log I still see the HTTP/1.1 202 Accepted
And the log entry is NOT added to the syslog server.

So if I use curl this works;
/QOpenSys/pkgs/bin/curl -X POST -H 'Content-Type: application/json' -d '{ "version": "1.1", "host": "example.org", "short_message
": "Testing from QSH using Curl", "level": 5, "_some_info": "foo" }' 'http://Bnelog1.xxxxxx.local:12201/gelf'

But if I use HTTPAPI Command
HTTPAPI URL('http://Bnelog1.xxxxxx.local:12201/gelf') DOWNLOAD('/home/msd/result.
txt') REQTYPE(*POST) UPLOAD('/home/msd/syslog.txt') TYPE('application/json') DEB
UG('/home/msd/debug.txt')
Nothing is received by the syslog server

The syslog.txt contains
{ "short_message": "This is a short message", "full_message":"This is the full message ", "host":"Hostname", "version":"Version
", "timestamp": "1629332852.490", "level": "01" }

What am I missing ?
Maybe I need to convert the data to ascii ? ccsid 1208 ?

Or ??

I don't know anything about the API you're calling, and I can't test with that. All I did was change it so that the 202 response was handled correctly. If there's another problem, then you need to tell me how to reproduce that.

What is in your result.txt? How about the debug.txt?

Also, I would suggest using the same JSON document in your HTTPAPI test that you're using in the cURL test. Your syslog.txt seems very strange to me. For example,the one in CURL says "version": "1.1", the syslog.txt says "version": "Version". I can't imagine that second one is a valid version number.

The result.txt is empty.

How to reproduce - very good question, let me work on that.
I will run a packet capture and see if I can identify a difference between the curl post and the httpapi post.
I was hoping that there may be some obvious difference between the curl option and the httpapi option that would suggest a reason for the failure.

I have updated the json to be the same as in the curl example but still the same result.

The debug.txt is as follows and I think the same as originally posted.
************Beginning of data**************
HTTPAPI Ver 1.45 released 2021-09-20
NTLM Ver 1.4.0 released 2014-12-22
OS/400 Ver V7R3M0

New iconv() objects set, PostRem=819. PostLoc=0. ProtRem=819. ProtLoc=0
http_persist_open(): entered
http_long_ParseURL(): entered
DNS resolver retrans: 2
DNS resolver retry : 2
DNS resolver options: x'00000136'
DNS default domain: XXXXXX.LOCAL
DNS server found: 192.168.126.2
DNS server found: 192.168.126.3
DNS server found: 10.100.0.210
Nagle's algorithm (TCP_NODELAY) disabled.
http_persist_post(): entered
http_persist_req(POST) entered.
http_long_ParseURL(): entered
http_long_ParseURL(): entered
do_oper(POST): entered
There are 0 cookies in the cache
POST /gelf HTTP/1.1
Host: Bnelog1.xxxxxx.local:12201
User-Agent: http-api/1.45
Content-Type: application/json
Content-Length: 181


sendraw(): entered
{ "short_message": "This is a short message", "full_message":"This is th efull message ", "host":"Hostname", "version":"Version", "timestamp": "1629332852.490", "level": "01" }
recvresp(): entered
HTTP/1.1 202 Accepted
content-length: 0
connection: keep-alive
SetError() #13: HTTP/1.1 202 Accepted
recvresp(): end with 202
recvdoc parms: identity 0
header_load_cookies() entered
recvdoc(): entered
SetError() #0:
recvdoc(): Receiving 0 bytes.
recvdoc(): Nothing to receive, exiting...
SetError() #13: HTTP/1.1 202 Accepted
http_close(): entered
************End of Data********************

Your latest message still shows the "bad" json. You said you made them the same, but this one is not the same as the one you showed with curl.