Sending gzipped files via http POST

Hi all,

Just wondered if anyone has tried this or may know the answer. I have gzipped files in unix and I am trying to send these via a http POST, but having issues. I've tested via postman, so know it's something I am doing wrong.

I have added 'Content-Type application/json", and "Content-Encoding gzip" to the header, and read in the file to use as the payload, but get the following when checking the response header: 

------------------------------
Simon Woolfall
Senior Software Engineer
Rocket Forum Shared Account
BELFAST GB
------------------------------

Simon,

Firstly I would look to turn on the logs via the protocolLogging function at level 10 to get a full trace of messages.
Secondly the client you are connecting to send the gzip encoding to, also has to accept the gzip encoding as part of the negotiations.

See if the protocolLogging output explains anything more.

LRET = protocolLogging("secureCallLog.LOG","ON","10")  ... turns the logging on to level 10 to a trace file called secureCalllog.LOG
LRET = protocolLogging("secureCallLog.LOG","OFF","10") ... turns the logging off in that example

Please turn logging off, after turning it on , otherwise it will remain on.

Thanks,



------------------------------
Jonathan Smith
UniData ATS
Rocket Support
------------------------------

Hi all,

Just wondered if anyone has tried this or may know the answer. I have gzipped files in unix and I am trying to send these via a http POST, but having issues. I've tested via postman, so know it's something I am doing wrong.

I have added 'Content-Type application/json", and "Content-Encoding gzip" to the header, and read in the file to use as the payload, but get the following when checking the response header: 

------------------------------
Simon Woolfall
Senior Software Engineer
Rocket Forum Shared Account
BELFAST GB
------------------------------

Hello Simon,

You do not mention how you are reading in the zip file.
I am also assuming you are using UniData.
Are you using the OSREAD function?

If you are, are you doing "NOCONVERT ON" before the OSREAD?

cheers

Nik

------------------------------
Nik Kesic
DevOps
LKQ
NASHVILLE TN US
------------------------------

Hello Simon,

You do not mention how you are reading in the zip file.
I am also assuming you are using UniData.
Are you using the OSREAD function?

If you are, are you doing "NOCONVERT ON" before the OSREAD?

cheers

Nik

------------------------------
Nik Kesic
DevOps
LKQ
NASHVILLE TN US
------------------------------

Hi,

Just via a standard READ command, and its UniVerse.

Thanks
Simon

------------------------------
Simon Woolfall
Senior Software Engineer
Rocket Forum Shared Account
BELFAST GB
------------------------------

Hi,

Just via a standard READ command, and its UniVerse.

Thanks
Simon

------------------------------
Simon Woolfall
Senior Software Engineer
Rocket Forum Shared Account
BELFAST GB
------------------------------

Simon,

A standard and unfiltered BASIC READ of a file will probably  start converting characters. For example, an O.S. file delimiter (LF or CRLF depending on the O.S.)  - would be converted to field marks. Where a true binary file is involved then any attempt to POST could be frustrated before it even begins (hence the prior mention of NOCONVERT ON by Nik).

From the UniData BASIC reference documentation:

• Warning: Do not use UniBasic READ and WRITE commands to open or modify binary data in DIR type files (for example, BP). Doing so can corrupt data in the file. Instead, use OSREAD or OSBREAD after executing the UniBasic NOCONVERT command.

The closest approximation in UniVerse is I believe READBLK (from the UniVerse BASIC reference guide)

• Note that READBLK is a byte level operation and returns a string in which each character will represent one byte from the file and hence is always in the range char(0) to char(255). When used with the ENCODING clause, the bytes value is the number of bytes to be read, not the character count in the decoded data.

In this scenario I would be tempted to execute a 'curl' shell command to send the file in question at the O.S. level, though if the source data was URL encoded prior to being  READ it may then succeed. Please  be aware that the payload could be very large indeed - even before encoding.

I recommend opening a formal ticket through your support channel  on this if executing a 'curl' command does not give a solution..

Regards

JJ

------------------------------
John Jenkins
Thame, Oxfordshire
------------------------------

Simon,

A standard and unfiltered BASIC READ of a file will probably  start converting characters. For example, an O.S. file delimiter (LF or CRLF depending on the O.S.)  - would be converted to field marks. Where a true binary file is involved then any attempt to POST could be frustrated before it even begins (hence the prior mention of NOCONVERT ON by Nik).

From the UniData BASIC reference documentation:

• Warning: Do not use UniBasic READ and WRITE commands to open or modify binary data in DIR type files (for example, BP). Doing so can corrupt data in the file. Instead, use OSREAD or OSBREAD after executing the UniBasic NOCONVERT command.

The closest approximation in UniVerse is I believe READBLK (from the UniVerse BASIC reference guide)

• Note that READBLK is a byte level operation and returns a string in which each character will represent one byte from the file and hence is always in the range char(0) to char(255). When used with the ENCODING clause, the bytes value is the number of bytes to be read, not the character count in the decoded data.

In this scenario I would be tempted to execute a 'curl' shell command to send the file in question at the O.S. level, though if the source data was URL encoded prior to being  READ it may then succeed. Please  be aware that the payload could be very large indeed - even before encoding.

I recommend opening a formal ticket through your support channel  on this if executing a 'curl' command does not give a solution..

Regards

JJ

------------------------------
John Jenkins
Thame, Oxfordshire
------------------------------

Hi John,

Thanks for your reply, kinda guessed the read was messing with the data, so used OPENSEQ/READBLK and that has worked for me. Thanks everyone for your help on this. Appreciated.

Simon

------------------------------
Simon Woolfall
Senior Software Engineer
Rocket Forum Shared Account
BELFAST GB
------------------------------