Re: Uploading Files with CGI.pm results in 0 byte files

[imp]

in reply to Uploading Files with CGI.pm results in 0 byte files

I tested the provided code locally and did not have any issues with the upload. The problem is elsewhere, whether with other unprovided code, or with local modules/web service/file system.

Here's a standalone version of the provided code that dumps the file to the browser, along with the temp file name.

#!/usr/bin/perl
use strict;
use warnings;
use CGI;

my $output   = '';
my $query    = CGI->new();
my $filename = $query->param("uploadfile_0");
my $upload   = $query->upload("uploadfile_0");
$output     .= "Temp file: " . $query->tmpFileName($filename) . "\n";

if (!$upload) {
    $output .= "<p>CGI.pm failed to upload the file.</p>";
}
else {
    $output .= "----- Contents: ------\n";
    while (<$upload>) {
        $output .= $_;
    }
}
print "Content-type: text/plain\n\n";
print $output;

Could you provide some details about your environment?
e.g.:

OpenBSD 3.5
Apache 1.3.34
perl 5.8.2
CGI 3.20

[Anonymous Monk]

I too have gotten a stand alone version working (before i saw your reply, that was my next step after posting). I've copied and pasted the working code into my program with no luck. Loaded all the modules i'm loading in the real scripts in the standalone and the standalone still works fine.

I'm about ready to go back and kick the server.

Redhat AS4 fully patched perl 5.8.5-36.RHEL4, which ever version of CGI comes with it.

[Anonymous Monk]

Found the problem.

I was checking authentication using CGI::Session and creating a $cgi object with it.

Apparently, if you have form data and don't use the first CGI object you create you lose the upload, but retain all the additional data.

Learn something new every day. I've been creating multiple CGI objects for years without any problems. From now on i'll create just one and pass it around to functions as needed.

[friedo]

That's because POST data comes into the program on STDIN, as opposed to the environment table which is used for GET data ($ENV{QUERY_STRING}). STDIN can only be read once, and so the first CGI object instantiated will suck it all up.

[trwww]

That's because POST data comes into the program on STDIN, as opposed to the environment table which is used for GET data ($ENV{QUERY_STRING}). STDIN can only be read once, and so the first CGI object instantiated will suck it all up.

friedo++

Also, this is why app frameworks like CGI::Application and Catalyst are pure genious. In the case of CGI::Application, one says:

$self->query

and knows he has the right object.

If a code base has this particular type of bug, I'd probably be willing to bet there is a host of other worse ones lurking. I know because I've written them :-)

At a minimum, if CGI->new is being called more than once per request there are troubles. If it is being done with the session object, (sometimes) there are serious troubles.

The session manager I use is used in production on a large quantity of computers. It has probably been debugged by more than 100 people. The following is an example usage:

CGI::Application::Plugin::Session example

Building frameworks is fun, but if you're trying to up your productivity, check out a perl web app framework.

If you didnt read the link above, at least consider the following:

http://search.cpan.org/search?query=CGI::Application::Plugin&mode=all

There you'll find a html popup dbi profiler, database driven session based auth, heck even a CAPTCHA plugin.

trwww
-- beating on the perl web app framework drum