The work was done by Ron Egyed, RJE Consulting Inc, New Port Richey (FL), U.S..

The way this feature works is very simple:

• If a <form ...> includes the parameter enctype="multipart/form-data", it can upload PC files.
• A nice way to let the user browse the PC an pick up the file to be uploaded is that of using
  <input type="file" name="namexxx" size="..." device="files">
  where namexxx is a name of your choice.
• When the form is submitted, a copy of the PC file is sent to the HTTP server
• As soon as the CGI program runs subprocedure zhbGetInput(), the file is uploaded to IFS directory /tmp
• Subprocedure zhbGetInput() provides two input variables that can be received by subprocedure zhbGetVar():
  • the first, named namexxx, contains the name of the PC file (e.g. mytext.txt).
    Note. Usually browsers, when uploading a file to a server, transfer just the PC file name, not its path. This is done for security reasons. However, MS Internet Explorer may also transfer the file path (e.g. C:\mypath\mytext.txt). This is a problem, therefore we recommend to set to disabled the following Internet Explore setting:
    Tools-> Internet Options-> Security-> Customized level-> Include local directory path when uploading files to a server.
  • the second, named namexxx_tempfile, contains the path and the name of the IFS file uploaded from the PC file. Files are always uploaded to IFS directory /tmp and are assigned unique names (e.g. /tmp/mytext_395935_20110128094216294000.txt ). It is then up to the CGI program to rename the uploaded stream file and to move it to the appropriate IFS directory.
  Please note that namexxx is the name you have assigned to the input variable in your form.
• The CGI program is of course able to receive via subprocedure zhbGetVar() any other input parameter sent from the form.

A sample program taking advantage of the file-upload feature is the ILE-RPG CGI program CGIDEV2/UPLOAD.
To run it click here
To display its source click here
To display its external HTML click here.

For more details on this technique, take a look at an Easy400 similar utility named FUPLOAD2, this page.

Warning for MS Internet Explorer users
If you are using the MicroSoft Internet Explorer browser, it is mandatory that you disable the following default setting:
Tools->Internet Options->Security->Include_local_directory_path_when_uploading_files_to_a_server

Validating a file upload request

1. Client validation
In principles, this is the best approach, as the validation process takes place on the client and is immediate. What you need is some JavaScript function validating the file to be uploaded.
This Javascript function must then be made available in the external HTML of your upload program.
The only validation that makes sense on the client side is on the extension of the file to be uploaded.
As an example, the external HTML of CGI program CGIDEV2/UPLOAD contains a JavaScript validation function named ValidateExtension(). This function works on three arguments:
1. the name of the file to be uploaded
2. a constant (possible values 'yes' or 'no') telling whether extension validation should take place
3. an array of allowed extensions
Parameters b) and c) should be customized according to the installation needs. However, as this may be an hazard, a special command - cgidev2/updalwext - has been developed to customize these parameters, which are then set in the script from program UPLOAD as output variables.


2. Server validation
A file upload goes through two stages:
1. The PC file(s) are trasmitted to the server along with any other input field. This is done by the HTTP server.
2. The application program (the CGI program) takes care of receiving the input variables and the input file(s). This occurs when CGIDEV2/CGISRVPGM2 subprocedure ZhbGetInput() is invoked. Usually ZhbGetInput() would copy the input file(s) to IFS stream file(s) in directory /tmp.
   However, before creating an IFS stream file, subprocedure ZhbGetInput() checks whether an Exit Point Validation User Program is available and, if so, asks it to validate the file.
   • If the validation is successful, the PC file is uploaded to an IFS stream file.
   • If the validation fails, no IFS stream file is created, the name of the file is returned as
     *** NOT VALIDATED ***
     and an error message is written to the CGIDEBUG file.
What you could then do is to write such a Validation User Program and make it available for the appropriate Exit Point. This is how you do it:
1. Writing the upload validation program
• The validation program receives two parameters, the qualified name (path, file name and extension) of the IFS stream file to be created and a return code:

  D UPLOADVAL pr D filename 1024 varying D retcode 10i 0 D UPLOADVAL pi D filename 1024 varying D retcode 10i 0

• A value 0 (zero) of the return code means that the PC file passed the validation, a value -1 means that the validation was not passed (failed).
• Most sensitive items for validation are the file extension and the user name (the user name, to be available, requires user validation through the appropriate HTTP directives).
• The validation program could as well return a different qualified name for the IFS stream file to be created.
• As an example, you could look at program CGIDEV2/UPLOADVAL, press here to display its source. Please note that this validation program accepts only files with extension csv.
2. Making the upload validation program available to the Exit Point
1. Run command cgidev2/updexitp. The following screen appears:

   Update Exit Points Type option, press Enter. 2=Change Exit point User program FILE-UPLOAD-001 F3=End

2. Type 2 in front of the FILE-UPLOAD-001 exit point name to receive the following screen:

   Update Exit Points Exit point . . . . . . . . FILE-UPLOAD-001 User program . . . . . . . Library . . . . . . . . F3=End F12=Cancel

   Then type the name and the library name of your upload validation program.
   Just as an example you could specify program CGIDEV2/UPLOADVAL.
   We suggest to create your own file upload validation program in some library of yours.
   Never change CGIDEV2 programs, nor develop objects in library CGIDEV2: when installing the next CGIDEV2 release your changes would disappear.