Hi Nordic Team,
I noticed a potential issue while migrating from SLM v1.4.0 to v1.9.0. In addition to the inversion of the <state> representation in #XHTTPCRSP introduced in v1.6.0, I understand that the HTTP response headers and body are now transferred in separated chunks (source code), rather than aggregated into a single #XHTTPCRSP response in older SLM versions. The SLM documentation also reflects this, and expects that the response header would be preceded by #XHTTPCRSP:<header_length>,0 to indicate more data (i.e., the response body) would come.
However, I encountered an unexpected response when testing with my HTTP API (and reproduced via httpbin.org as shown below). In some cases, the #XHTTPCRSP URCs preceding both the response header and body have <state> set as 1. This may be counterintuitive to developers (especially migrated from earlier versions) who would parse #XHTTPCRSP:<header_length>,1 as the final chunk. (I guess this is due to the header and body co-existed in the buffer in shorter HTTP responses, such that final_data = 1 is emitted twice in lines 105 and 111 in slm_at_httpc.c.)
> AT#XHTTPCCON=1,"httpbin.org",443,<sec_tag_redacted>
#XHTTPCCON: 1
OK
> AT#XHTTPCREQ="GET","/get","Content-Type: text/plain\r\nContent-Length: 4\r\n",4
OK
#XHTTPCREQ: 1
> test
#XHTTPCREQ: 0
#XHTTPCRSP:230,1
HTTP/1.1 200 OK
Date: Mon, 28 Feb 2022 04:51:03 GMT
Content-Type: application/json
Content-Length: 264
Connection: keep-alive
Server: gunicorn/19.9.0
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
#XHTTPCRSP:264,1
{
"args": {},
"headers": {
"Content-Length": "4",
"Content-Type": "text/plain",
"Host": "httpbin.org",
"X-Amzn-Trace-Id": "<removed>"
},
"origin": "<removed>",
"url": "https://httpbin.org/get"
}
#XHTTPCRSP:0,1
#XDATAMODE: 0
Whereas the response using the same request parameters as the example yields the expected result:
> AT#XHTTPCCON=1,"httpbin.org",443,<sec_tag_redacted>
#XHTTPCCON: 1
OK
> AT#XHTTPCREQ="PUT","/put","User-Agent: curl/7.58.0\r\naccept: */*\r\nCK: DEADBEEFDEADBEEFDE\r\nContent-Type: application/json\r\nContent-Length: 224\r\n",224
OK
#XHTTPCREQ: 1
> {"id":"123456789","name":"iamchanged","desc":"My Hygrometer","type":"general","uri":"http://a.b.c.d/hygrometer","lat":24.95,"lon":121.16,"attributes":[{"key":"label","value":"thermometer"},{"key":"region","value":"Taiwan"}]}
#XHTTPCREQ: 0
#XHTTPCRSP:231,0
HTTP/1.1 200 OK
Date: Mon, 28 Feb 2022 05:34:14 GMT
Content-Type: application/json
Content-Length: 1044
Connection: keep-alive
Server: gunicorn/19.9.0
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
#XHTTPCRSP:793,0
{
"args": {},
"data": "{\"id\":\"123456789\",\"name\":\"iamchanged\",\"desc\":\"My Hygrometer\",\"type\":\"general\",\"uri\":\"http://a.b.c.d/hygrometer\",\"lat\":24.95,\"lon\":121.16,\"attributes\":[{\"key\":\"label\",\"value\":\"thermometer\"},{\"key\":\"region\",\"value\":\"Taiwan\"}]}",
"files": {},
"form": {},
"headers": {
"Accept": "*/*",
"Ck": "DEADBEEFDEADBEEFDE",
"Content-Length": "224",
"Content-Type": "application/json",
"Host": "httpbin.org",
"User-Agent": "curl/7.58.0",
"X-Amzn-Trace-Id": "<removed>"
},
"json": {
"attributes": [
{
"key": "label",
"value": "thermometer"
},
{
"key": "region",
"value": "Taiwan"
}
],
"de
#XHTTPCRSP:251,1
sc": "My Hygrometer",
"id": "123456789",
"lat": 24.95,
"lon": 121.16,
"name": "iamchanged",
"type": "general",
"uri": "http://a.b.c.d/hygrometer"
},
"origin": "<removed>",
"url": "https://httpbin.org/put"
}
#XHTTPCRSP:0,1
#XDATAMODE: 0
My revised approach is (obviously) to keep on parsing incoming data until receiving #XHTTPCRSP:0,1, yet I believe Nordic can better document this behavior to avoid confusion.
Thanks!
