Serial LTE Monitor Application: Contradictory HTTP documentation

Question

Hi! We are updating our application from NCS 1.9 to NCS 2.1. In the documentation of the HTTP AT command of the 2.X versions of NCS the XHTTPCRSP notification is documented contradictory. In the examples above it seems to be formatted like so:

<payload>
#XHTTPRSP:<length>,<state>

eg in the example of

AT#XHTTPCREQ="POST","/post","User-Agent: slm\r\naccept: */*\r\n","application/json",17

OK

#XHTTPCREQ: 1
{"hello":"world"}+++
#XHTTPCREQ: 0

#XDATAMODE: 0

HTTP/1.1 200 OK
Date: Tue, 01 Mar 2022 05:22:28 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 359
Connection: keep-alive
ETag: W/"167-2YuosrP0ARLW1c5oeDiW7MId014"
Vary: Accept-Encoding
set-cookie: sails.sid=s%3A_b9-1rOslsmoczQUGjv93SicuBw8f6lb.x%2B6xkThAVld5%2FpykDn7trZ9JGh%2Fir3MVU0izYBfB0Kg; Path=/; HttpOnly


#XHTTPCRSP:342,1

Though, if you scroll down to the documentation of #XHTTPRSP: itself it lists the following format:


#XHTTPCRSP=<byte_received>,<state><CR><LF><response>

So in the examples the data comes first, and after comes the notification. In the documentation of the command itself, the notification comes first, and after the data. Which of those two is the correct implementation?

Håkon Alseth · Accepted Answer

Hi, 
 
 Thank you for reporting this back to us! 
 So in the examples the data comes first, and after comes the notification. In the documentation of the command itself, the notification comes first, and after the data. Which of those two is the correct implementation? 
 This is a clear in the documentation, as the response comes first. I'll make sure that the developers are aware of this issue. 
 
 Kind regards, 
 Håkon

Serial LTE Monitor Application: Contradictory HTTP documentation

Top Replies