I have a HTTP/Serial driver that parses a gzip-encoded response. The issue that I’m currently facing is that the decompressed gzip byte array returns a byte-length of 0. Upon further inspection, I realised that the parameter storing the compressed gzip byte array had a length of 1104, as compared to wireshark, which had a length of about 30k bytes.
I am capturing the response in a serial command/response pair where the payload is stored in a string of length type “next param”. With this information I am lead to believe that the parameter is insufficient in fully capturing the response data, but I am unsure how to store the leftover payload, decompress it and concatenate the responses together for parsing.
Hi Shawn, the driver makes a HTTP post request through an xml string that is passed serially to the device. The device is parsing the response serially and it stores the gzip-compressed bytes in a parameter which is then processed by a QAction.
We did some preliminary tests on Wireshark to see if the device was sending data. The file was completely received on Wireshark and the full xml string could be retrieved.
I am unable to verify this on Dataminer as I am stuck at decompressing the gzip-compressed bytes array. It always returns a length of 0 hence there is no way for me to determine how much of the xml string is parsed.
Hope this gives you more context.
Hi Chian,
It could be that the (string) data is being truncated because of 0x00 bytes in the received data. To solve this you could try to read the raw binary data from the parameter using the GetData() method. An example of how to do that can be found here: https://docs.dataminer.services/develop/devguide/Connector/LogicQActionsExamples.html#processing-gzip-compressed-data.
What protocol/API and method are you using to make the request? Did you try to query outside of Dataminer like via Postman, how did it go and was the file completely received? Seems like your getting a partial zip file like maybe the connection was interrupted during transfer maybe?