You can use it to create the form for uploading the file (the form "enctype" has to be "multipart/form-data"). And then you can use it to proces the file upload, the title, and the description.

use CGI;

my $query = new CGI;
my $fh = $query->upload('uploaded_file');

open OUTPUT, ">/foo/save" or die "Can't open: $!";
while (<$fh>) {
    print OUTPUT;
}
close OUTPUT or die "Can't close: $!";

my $title = $query->param('title');
my $description = $query->param('description');

# now write them to a file...
[download]

Should perhaps be:

< my $fh = $query->upload('upload_file');
> my $fh = $query->param('uploaded_file');
# file input control is named "uploaded_file"
and
< open OUTPUT, "/foo/save" or die "Can't open: $!";
> open OUTPUT, "> /foo/save" or die "Can't open: $!";
[download]

One problem I've found is that when uploading files larger than around ~60-70k, I get a problem in trying to instantiate CGI.pm. (Apache flips me the bird and takes me to an error screen). Is this a known problem? Has anyone else struck this?

You're right about the open on the OUPUT filehandle. I think we're both right on the first thing (param vs. upload), though. :) As the CGI.pm docs say this:

    To be safe, use the upload() function (new in version
    2.47).  When called with the name of an upload field,
    upload() returns a filehandle, or undef if the parameter
    is not a valid filehandle.

            $fh = $query->upload('uploaded_file');
[download]

Calling param on an uploaded file field gives you a thing that's both a string and a filehandle. Using upload just makes sure you get a filehandle, as it's less of a security risk.

As to your question re: big uploads: do you get any out of memory errors? 60-70k doesn't seem like *that* big a value. Could it be a POST limitation?