Re: CGIDEV2 file upload data conversion

Thanks.

I've now stopped the base64 encoding on the upload. The results look good. I seem to be getting the correct hex values in the DB2 table.

I'm giving the users the ability to upload any type of file. When the users wish to view the uploaded files, files are downloaded, specifying...

Content-Type: application/octet-stream
Content-Disposition: attachment; filename="xxx";

Working fine for XML, TXT, JPEG files etc., but have problems with PDF, DOC, XLS.

When I use Notepad to compare the original uploaded file to the downloaded file, no differences. Except, if I perform SaveAs in Notepad, I see the original file has ANSI encoding specified, whereas the uploaded/downloaded file has Unicode encoding specified.

Any ideas?




-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Bradley Stone
Sent: 29 November 2016 18:13
To: Web Enabling the IBM i (AS/400 and iSeries) <web400@xxxxxxxxxxxx>
Subject: Re: [WEB400] CGIDEV2 file upload data conversion

Hi, Sean.

It looks like the data that "worked" was plain ascii and the other was base
64 encoded (but still ASCII).

There should be no conversion of the data from ASCII to EBCDIC in your case since the content type is application/[whatever].

I'd double check the headers on one that doesn't base64 encode the data.
And double check what you're using for the upload option to see if one
base64 encoded and one didn't.

Or, you may need to read the headers and if it is base64 encoded, decode it before storing it in your IFS.

Brad
www.bvstools.com.

On Tue, Nov 29, 2016 at 9:55 AM, McGovern, Sean <sean.mcgovern@xxxxxxxxxxxxx

wrote:

About a month ago, I installed the latest version of CGIDEV2, and
developed functionality that allows users to upload file attachments
to DB2 table via the web, with the ability to download from the DB2
table. In this way, files can be attached to 'orders' and users can
view these files when they wish. All was working well (even made a
video demonstrating the process to users).

Now paperwork has been approved for me to promote this development to
a QA environment. I tested the functionality again and hit an issue
that I've been unable to resolve. I'm unaware of any changes that have
been made in the past month.

Now, when the file attachment data reaches CGISRVPGM2, it appears to
have been converted and I don't know why.

I have specified...

CGIConvMode %%EBCDIC/EBCDIC%%
DefaultFsCCSID 937
DefaultNetCCSID 1208

If, for example, I attempt to upload a PDF document, I can see in
browser debug, that the post contains...

Content-Disposition: form-data; name="Filedata"; filename="Imp 4991.pdf"
Content-Type: application/pdf
Content-Transfer-Encoding: base64

JVBERi0xLjYN...

The above base64 data translates to "%PDF-1.6", which is what I see
when I open the PDF document in Notepad. I'm unsure whether it should
be base64 encoded, but I believe this was working this way previously.

When I did this a month ago, I got the correct hex values in the DB2
table...

255044462D312E31
%PDF-1.6
(CCSID 819)

Now, I get...

4A56424552693078

Debugging, I see this is the data (in hex) that is read and written to
the temporary filename in CGISRVPGM2. CGISRVPGM2 doesn't appear to be
converting this data.

I don't know why I'm now getting 4A564...whereas previously I got
2550444...??

Thanks for any help.




--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing list To post a message email: WEB400@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing list To post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/web400.