CGI to Receive Any File by POST

Sannyasin Sivakatirswami katir at
Wed Mar 24 00:19:16 EST 2004

We are tightening up on FTP on our server and opening up AFP for remote 
mac users... but our Windows collobarators will need another way to 
send files.

I'm thinking to serve a simple upload.html file with with a client side 
form  <input type="file select">  file picker that sends the chosen 
file by POST to a server Revolution CGI that saves the file to a drop 
box, or an authorized user's directory. I am a complete newbie in this 

On the CGI end, one might assume it could be a simple as:

on startup
    read from stdin until empty
  put  urlDecode (it)  into tDataIn
    split tDataIn by "&" and "="
put tDataIn["_User"] into tUser
    put tDataIn["_FileName"] into tFileName
     put tDataIn["_Data"] into tData

# our users have pre-built directories with permissions
# set to allow the CGI to write to them

put "../incoming/" & tUser & "/" & tFileName into tPath
put tData into url ("binfile:" & tPath)

## get result, inform user Upload was successful etc.

end startUp

But I suspect there are other issues lurking here:

1) There was an old problem with the MC solaris engine  a couple years 
ago, wherein a large amount of data was truncated using the "read from 
stdIn until empty" syntax... Scott Raney had a work around for that...I 
think I have it somewhere...  I'm wondering if anyone knows if this is 
resolved and if the simple form "ready until empty" works now for large 
blocks of incoming data? We'll be running this on an OSX server using 
the latest Revolution Darwin engine.

2) Typically we could be receiving PDFs, MS Word Files, scanned images 
and possibly even InDesign CS files from remote collaborators. i.e. a 
wide variety of binary formats. Since the file data could be anything, 
I assume using the "binfile" form is correct. Right? but what about the 
preceeding urlEncode/urlDecode process -- does it tamper with the data?

3) If the file is big and the user has a lo-bandwidth connection... it 
will take time... anyone have any html code that does a progress bar? 
(not likely) or put another way what  is the standard practice to make 
sure the user doesn't quit his browser and is informed when the POST is 
complete? Do I need some JAVA here? ( I don't know JAVA and would have 
to find a pre-mixed cake)

Since the number of remote collaborators is finite, one could also 
create a Revolution desktop standalone app that does the job and give 
this to them, but I'm thinking HTML file select should suffice...and 
less maintenance in the long run.

Any insights will be appreciated.


Sannyasin Sivakatirswami
Himalayan Academy Publications
at Kauai's Hindu Monastery
katir at,

More information about the Use-livecode mailing list