How can I transfer file from client? Futher problems inside...

derek_blink has asked for the wisdom of the Perl Monks concerning the following question:

I'm just the beginner in Perl and surely have some problems.. When I want to transmit some files from form, I use "enctype=multipart/form-data" and "method=post". In script:

read(STDIN,$form_data,$ENV{'CONTENT_LENGTH'});
open (FILE,"something.log");
print $form_data;
close(FILE);
[download]

Doing all that and then checking have this: in file "something.log":

-------------   1234567890  #(just some --- and some numbers

And nothing more?! What's that and where is my problem? Maybe in apache?

Originally posted as a Categorized Question.

Comment on How can I transfer file from client? Futher problems inside... Download Code

Replies are listed 'Best First'.
Re: How can I transfer file from client? Futher problems inside... by Corion (Patriarch) on Jul 11, 2000 at 12:09 UTC
Of course, the canonical reply would be to use `CGI.pm` which handles all of this nasty stuff quite well and comes with about every Perl distribution I know. CGI.pm also takes care of the tempfile creation, removal and I guess that there are no backdoors or exploits in CGI.pm itself. There are at least two things wrong with the code : First, no error checking. Opening a file should always be done like this (in my holy opinion) : `local *FILE; open( FILE, "> $file" ) or die "Couldn't create '$file' : $!\n"; ... close( FILE );` [download] Of course, it's not always adequate to `die()`, but at least a `warn` is in place and for tools or CGI stuff, a `die` isn't bad, as the stuff will show up in the error log of the server. The second thing is, that the file will be clobbered under Win32, as it is used for binary data and no `binmode()` is used on the file handle. This will not affect writing ASCII data in any way and it will also have no effect under UNIX platforms. Looking further through the code, I see that `$form_data` is printed to STDOUT instead of (as it maybe should be ?) to FILE. Maybe that's already the error... Also, because there won't be more (or less) bytes available on STDIN than `$ENV{'CONTENT_LENGTH'}` indicates, reading from STDIN could simply be done by using the following code : `{ local $/ = ""; $form_data = <>; }; # $form_data now contains the submitted stuff` [download] But I would really use CGI.pm for such stuff like file submission !	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: How can I transfer file from client? Futher problems inside...
by Corion (Patriarch) on Jul 11, 2000 at 12:09 UTC

Of course, the canonical reply would be to use CGI.pm which handles all of this nasty stuff quite well and comes with about every Perl distribution I know. CGI.pm also takes care of the tempfile creation, removal and I guess that there are no backdoors or exploits in CGI.pm itself.

There are at least two things wrong with the code :
First, no error checking. Opening a file should always be done like this (in my holy opinion) :

  local *FILE;
  open( FILE,  "> $file" ) or die "Couldn't create '$file' : $!\n";
  ...
  close( FILE );
[download]

die()

warn

die

The second thing is, that the file will be clobbered under Win32, as it is used for binary data and no binmode() is used on the file handle. This will not affect writing ASCII data in any way and it will also have no effect under UNIX platforms.

Looking further through the code, I see that $form_data is printed to STDOUT instead of (as it maybe should be ?) to FILE. Maybe that's already the error... Also, because there won't be more (or less) bytes available on STDIN than $ENV{'CONTENT_LENGTH'} indicates, reading from STDIN could simply be done by using the following code :

{
  local $/ = "";
  $form_data = <>;
};

# $form_data now contains the submitted stuff
[download]

[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom