Buffering bug - QHTTPPUTFILE

[xcalibur]

Hi,

I am trying to upload a 37KB (jpeg) file to a remote server using QHTTPPUTFILE. All the bytes are uploaded, but anything larger than ~7.5KB gets corrupted. Files are transferred to UFS before I start the upload. I have confirmed that the file in UFS is correct.

I have attached the original file and the resulting corrupted file.

There appears to be a buffering bug in the QHTTPPUTFILE function. Can you provide any assistance?

Module: EG800Q-EU
Firmware version: EG800QEULCR01A09M04_01.201.01.201

[xcalibur]

@aghelan_loga Do you perhaps know what the issue could be? Would you be able to reproduce this on your side to check?

[aghelan_loga]

Dear @xcalibur ,

Thanks for sharing the sample files.

For AT+QHTTPPUTFILE, the file format used by the module depends on AT+QHTTPCFG=“requestheader”. If requestheader is set to 0, the file in UFS must contain only the PUT body (your raw JPEG). If requestheader is set to 1, the file in UFS must contain the full HTTP PUT request header followed by the JPEG data. If you uploaded only the JPEG into UFS while requestheader is 1, the transmitted payload will not match a pure JPEG upload and the file received by the server can appear corrupted.

So please confirm your current requestheader setting, and if your UFS file contains only the JPEG, set requestheader to 0 and retry the upload.

Also, to confirm the UFS content integrity at the time of upload, please share the AT+QFUPL result that includes the upload size and checksum.

Best Regards,
Aghelan

[xcalibur]

Hi @aghelan_loga

I uploaded 2 separate files, and here are the results:

Log example:

AT+QHTTPCFG="sslctxid",1', result: 'AT+QHTTPCFG="sslctxid",1<r><r><n>OK<r><n>
AT+QSSLCFG="sslversion",1,4', result: 'AT+QSSLCFG="sslversion",1,4<r><r><n>OK<r><n>
AT+QSSLCFG="ciphersuite",1,0xFFFF', result: 'AT+QSSLCFG="ciphersuite",1,0xFFFF<r><r><n>OK<r><n>
AT+QSSLCFG="seclevel",1,2', result: 'AT+QSSLCFG="seclevel",1,2<r><r><n>OK<r><n>
AT+QMTCFG="SSL",3,1,1', result: 'AT+QMTCFG="SSL",3,1,1<r><r><n>OK<r><n>
AT+QSSLCFG="cacert",1,"cacert.pem"', result: 'AT+QSSLCFG="cacert",1,"cacert.pem"<r><r><n>OK<r><n>
AT+QSSLCFG="clientcert",1,"clientcert.pem"', result: 'AT+QSSLCFG="clientcert",1,"clientcert.pem"<r><r><n>OK<r><n>
AT+QSSLCFG="clientkey",1,"clientkey.pem"', result: 'AT+QSSLCFG="clientkey",1,"clientkey.pem"<r><r><n>OK<r><n>
AT+QMTCFG="session",3,0', result: 'AT+QMTCFG="session",3,0<r><r><n>OK<r><n>
AT+QHTTPCFG="contextid",1', result: 'AT+QHTTPCFG="contextid",1<r><r><n>OK<r><n>
AT+QHTTPCFG="requestheader",0', result: 'AT+QHTTPCFG="requestheader",0<r><r><n>OK<r><n>

SD file size: 9018 bytes
SD file MD5 checksum: efe2b0ac5f2a12bdcf10a81e44fdd052

Copying file to module storage...
+QFUPL: 9018,c08
 OK

UFS file MD5 checksum: efe2b0ac5f2a12bdcf10a81e44fdd052

AT+QHTTPURL=116,80
>
https://***********************************/134/2026-...
AT+QHTTPPUTFILE="UFS:upload_temp.jpg",80
OK
> 
+QHTTPPUTFILE: 0,200,0

---------------- File 1 (7165 bytes): ---------------

Original

Result

--------------------- File 2 (9018 bytes): --------------------

Original

Result

[aghelan_loga]

Dear @xcalibur,

Thanks for the detailed log and the two comparison images.

From what you’ve shared, the UFS file content is confirmed to be correct before the upload: the SD-side MD5 matches the UFS-side MD5, and the QFUPL result shows the expected size was stored successfully. You also have requestheader set to 0, which is the correct setting when the UFS file contains only the raw JPEG payload.

With that confirmed, the remaining difference is the HTTP upload step itself. The fact that the smaller file transfers correctly while the slightly larger file (9018 bytes) is consistently corrupted even though the server returns HTTP 200 strongly indicates a limitation or defect in the QHTTPPUTFILE upload path on EG800QEULCR01A09M04_01.201.01.201, rather than an issue with how the file was copied into UFS.

As a practical workaround on this firmware, please avoid QHTTPPUTFILE for binary image uploads and use QHTTPPUT to upload the data directly, or use the FTP/FTPS upload method if a file-based transfer is required. If you must continue using QHTTPPUTFILE, the appropriate next action is to move to a firmware version where this behavior is corrected, since the current results point to the module’s upload handling on this build.

Best Regards,
Aghelan

[xcalibur]

Thanks @aghelan_loga

QHTTPPUT seems to be working correctly. Is there somewhere I can formally log the firmware bug for QHTTPPUTFILE? I’ve gone through the change log for EG800QEULCR01A11M04_01.202.01.202, but there is no mention of a fix for QHTTPPUTFILE.

[aghelan_loga]

Dear @xcalibur ,

Thank you for the confirmation.
Kindly check your mail inbox.

Best Regards,
Aghelan