Hi there,
I noticed my BG95-M3 (FW BG95M3LAR02A03_01.014.01.014) hex-encodes the ETag option value in a nonsense way which seems to be a bug:
Get a backend resource in application/json format, response includes an ETag option for subsequent requests:
AT+QCOAPCFG="pdpcid",1,1
Preformatted text`AT+QCOAPCFG="trans",1,4,5
AT+QCOAPOPEN=1,"SOME_HOST",5683
AT+QCOAPHEADER=1,1000,1
AT+QCOAPOPTION=1,0,0,11,"SOME_PATH_SEGMENT"
AT+QCOAPOPTION=1,0,1,17,50
AT+QCOAPSEND=1,0,1,3
...
+QCOAPRECV: 1,1000,2.05,6,D304BFD0D34E,2,4,"F46ECDE6",12,50,183
<resource payload>
Request works, F46ECDE6 is the servers current resource ETag value.
Now request the same resource again, and this time apply the ETag:
AT+QCOAPCFG="pdpcid",1,1
AT+QCOAPCFG="trans",1,4,5
AT+QCOAPOPEN=1,"SOME_HOST",5683
AT+QCOAPHEADER=1,1000,1
AT+QCOAPOPTION=1,0,0,11,"SOME_PATH_SEGMENT"
AT+QCOAPOPTION=1,0,1,17,50
AT+QCOAPOPTION=1,0,2,4,"F46ECDE6"
AT+QCOAPSEND=1,0,1,7
The backend receives the following wrong ETag value: 46343645
Seems this resulted from taking the first 4 characters of my Etag option value (F46E), converting each into their ASCII HEX representation and concatenating the results - which obviously is wrong and makes it impossible to send the received ETag value back to the server in order to safe bandwidth!
Can anybody confirm this is a firmware issue?
Regards,
Sven