× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.