13 HTTP/1.1 202 Accepted - Attempting to post

[msddcb]

I have captured a packet trace and looking at the trace data I am seeing a slight difference.
Interestingly HTTPAPI is sending different size frames to curl so the data is over two frames.

Looking at the two postings we see slight difference;
POST /gelf HTTP/1.1..Host: Bnelog1.isuzu.local:12201..User-Agent: http-api/145..Content-Type: application/json..Content-Length: 186....{ "version":1.1","host":"example.org","short_message":"This is a short message","full_message":"This is the full message","timestamp": "1629332852.490", "level": 5,"_some_info": "foo" }

POST /gelf HTTP/1.1..Host: Bnelog1.isuzu.local:12201..User-Agent: curl/7.70.0..Accept: */*..Content-Type: application/json..Content-Length: 140....{ "version": "1.1", "host": "example.org", "short_message ": "Testing from QSH using Curl", "level": 5, "_some_info": "foo" }

So the main difference I see is the Accept*/* in the curl posting, not sure if this is the cause but is a starting point.

Here is the curl trace
0000 45 00 01 53 63 ae 40 00 40 06 00 00 0a 64 00 da E..Sc.@.@....d..
0010 c0 a8 7e 45 19 df 2f a9 16 7e dc 06 bd 4a 55 06 ..~E../..~...JU.
0020 80 18 80 00 00 00 00 00 01 01 08 0a ba 5b f4 54 .............[.T
0030 00 12 29 22 50 4f 53 54 20 2f 67 65 6c 66 20 48 ..)"POST /gelf H
0040 54 54 50 2f 31 2e 31 0d 0a 48 6f 73 74 3a 20 42 TTP/1.1..Host: B
0050 6e 65 6c 6f 67 31 2e 69 73 75 7a 75 2e 6c 6f 63 nelog1.isuzu.loc
0060 61 6c 3a 31 32 32 30 31 0d 0a 55 73 65 72 2d 41 al:12201..User-A
0070 67 65 6e 74 3a 20 63 75 72 6c 2f 37 2e 37 30 2e gent: curl/7.70.
0080 30 0d 0a 41 63 63 65 70 74 3a 20 2a 2f 2a 0d 0a 0..Accept: */*..
0090 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 61 70 Content-Type: ap
00a0 70 6c 69 63 61 74 69 6f 6e 2f 6a 73 6f 6e 0d 0a plication/json..
00b0 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 Content-Length:
00c0 31 34 30 0d 0a 0d 0a 7b 20 22 76 65 72 73 69 6f 140....{ "versio
00d0 6e 22 3a 20 22 31 2e 31 22 2c 20 22 68 6f 73 74 n": "1.1", "host
00e0 22 3a 20 22 65 78 61 6d 70 6c 65 2e 6f 72 67 22 ": "example.org"
00f0 2c 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 ,
0100 20 20 22 73 68 6f 72 74 5f 6d 65 73 73 61 67 65 "short_message
0110 22 3a 20 22 54 65 73 74 69 6e 67 20 66 72 6f 6d ": "Testing from
0120 20 51 53 48 20 75 73 69 6e 67 20 43 75 72 6c 22 QSH using Curl"
0130 2c 20 22 6c 65 76 65 6c 22 3a 20 35 2c 20 22 5f , "level": 5, "_
0140 73 6f 6d 65 5f 69 6e 66 6f 22 3a 20 22 66 6f 6f some_info": "foo
0150 22 20 7d " }

And here is the trace from HTTPAPI
0000 45 00 00 bc 63 b3 40 00 40 06 00 00 0a 64 00 da E...c.@.@....d..
0010 c0 a8 7e 45 1e de 2f a9 16 96 df b3 3e ad ac 2a ..~E../.....>..*
0020 80 18 80 00 00 00 00 00 01 01 08 0a ba 5c 1b 64 .............\.d
0030 00 12 50 19 50 4f 53 54 20 2f 67 65 6c 66 20 48 ..P.POST /gelf H
0040 54 54 50 2f 31 2e 31 0d 0a 48 6f 73 74 3a 20 42 TTP/1.1..Host: B
0050 6e 65 6c 6f 67 31 2e 69 73 75 7a 75 2e 6c 6f 63 nelog1.isuzu.loc
0060 61 6c 3a 31 32 32 30 31 0d 0a 55 73 65 72 2d 41 al:12201..User-A
0070 67 65 6e 74 3a 20 68 74 74 70 2d 61 70 69 2f 31 gent: http-api/1
0080 2e 34 35 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 .45..Content-Typ
0090 65 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 6a e: application/j
00a0 73 6f 6e 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e son..Content-Len
00b0 67 74 68 3a 20 31 38 36 0d 0a 0d 0a gth: 186....
0000 45 00 00 ee 63 b4 40 00 40 06 00 00 0a 64 00 da E...c.@.@....d..
0010 c0 a8 7e 45 1e de 2f a9 16 96 e0 3b 3e ad ac 2a ..~E../....;>..*
0020 80 18 80 00 00 00 00 00 01 01 08 0a ba 5c 1b 64 .............\.d
0030 00 12 50 19 7b 20 22 76 65 72 73 69 6f 6e 22 3a ..P.{ "version":
0040 22 31 2e 31 22 2c 22 68 6f 73 74 22 3a 22 65 78 "1.1","host":"ex
0050 61 6d 70 6c 65 2e 6f 72 67 22 2c 22 73 68 6f 72 ample.org","shor
0060 74 5f 6d 65 73 73 61 67 65 22 3a 22 54 68 69 73 t_message":"This
0070 20 69 73 20 61 20 73 68 6f 72 74 20 6d 65 73 73 is a short mess
0080 61 67 65 22 2c 22 66 75 6c 6c 5f 6d 65 73 73 61 age","full_messa
0090 67 65 22 3a 22 54 68 69 73 20 69 73 20 74 68 65 ge":"This is the
00a0 20 66 75 6c 6c 20 6d 65 73 73 61 67 65 22 2c 22 full message","
00b0 74 69 6d 65 73 74 61 6d 70 22 3a 20 22 31 36 32 timestamp": "162
00c0 39 33 33 32 38 35 32 2e 34 39 30 22 2c 20 22 6c 9332852.490", "l
00d0 65 76 65 6c 22 3a 20 35 2c 22 5f 73 6f 6d 65 5f evel": 5,"_some_
00e0 69 6e 66 6f 22 3a 20 22 66 6f 6f 22 20 7d info": "foo" }

What do you think ?

[msddcb]

Ok this is now working - Hurrah!

The issue in the end is embarrassing - turns out the timestamp I was using was invalid. My conversion to epoch when done manually was wrong, my program that does it was correct, so once I started using real data it was posted and processed correctly.

Thank you very much for the assistance.