reading buffered form data

[Jeff Thies]

I have a multipart form with several fields including an imput
type="file" that needs to be FTP'd elsewhere. The file input may be
quite large.

If I were to read in the file using CGI.pm, CGI.pm would slurp in the
entire "file" into a temp file, potentially exceeding the storage quota.

I think I'm going to have read from STDIN directly.

my $flag=0;
while(<STDIN>){
if($_=~/^-------/){ # reset if form boundary, do all form boundaries
start like that?
$flag=0;
}
if($flag){&appendFTP($_)}
if($_=~/name="name_of_file"/){ # look for form name
$flag=1;
}
}

That seems a bit simple and crude. Do I need to do this?:
$_ =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg; (before
appendFTP)

Do I need to filter out the "Content-type: ...\n\n" that seems to start
the file?

What else have I overlooked?

Jeff

 

[Greg Bacon]

: I have a multipart form with several fields including an imput
: type="file" that needs to be FTP'd elsewhere. The file input may be
: quite large.
:
: If I were to read in the file using CGI.pm, CGI.pm would slurp in
: the entire "file" into a temp file, potentially exceeding the storage
: quota.

Doesn't your provider at least enforce separate quotas for temporary
directories such as /usr/tmp, /var/tmp/, and /tmp?

: I think I'm going to have read from STDIN directly.
: [...]

Probably a bad idea. Have you considered patching CGI.pm to return
the file data in a scalar? Even so, what are you going to do with
the data then? Net::FTP deals in terms of files.

Greg

 

[Jeff Thies]

: I have a multipart form with several fields including an imput
: type="file" that needs to be FTP'd elsewhere. The file input may be
: quite large.
:
: If I were to read in the file using CGI.pm, CGI.pm would slurp in
: the entire "file" into a temp file, potentially exceeding the storage
: quota.

Doesn't your provider at least enforce separate quotas for temporary
directories such as /usr/tmp, /var/tmp/, and /tmp?

They seem to vary. At least one I work with doesn't, which has been a
big problem in the past.

: I think I'm going to have read from STDIN directly.
: [...]

Probably a bad idea. Have you considered patching CGI.pm to return
the file data in a scalar?

Nope. Is that a tough thing to do? I assumed that it was written in C,
which I have only a passing knowledge of. I'll go look now...

Even so, what are you going to do with
the data then? Net::FTP deals in terms of files.

Well maybe I'm wrong but I see that Net::FTP has an append method.

Thanks for the reply, after I posted this I realized this may have been
more of a CGI that perl question

Cheers,
Jeff

 

[Greg Bacon]

: Greg Bacon wrote:
:
: > Doesn't your provider at least enforce separate quotas for temporary
: > directories such as /usr/tmp, /var/tmp/, and /tmp?
:
: They seem to vary. At least one I work with doesn't, which has been a
: big problem in the past.

It surprises me that CGI.pm doesn't let you set a limit on uploaded
file size.

: > Probably a bad idea. Have you considered patching CGI.pm to return
: > the file data in a scalar?
:
: Nope. Is that a tough thing to do? I assumed that it was written in C,
: which I have only a passing knowledge of. I'll go look now...

CGI.pm is written in Perl. Patching wouldn't be beginner-friendly,
though.

: > Even so, what are you going to do with
: > the data then? Net::FTP deals in terms of files.
:
: Well maybe I'm wrong but I see that Net::FTP has an append method.

Right, but append's arguments are filenames. If the temp file is too
big to write, then how will you use Net::FTP::append?

Net::FTP::appe [sic] method could be useful, but you'd still need to do
a little legwork.

: Thanks for the reply, after I posted this I realized this may have
: been more of a CGI that perl question

Being lazy and more bug-prone than I'd like, I'd much rather use
tried-and-true code such as the CGI module than roll my own. YMMV.

Greg