Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the CGI CPAN distribution.

Report information
The Basics
Id: 11873
Status: rejected
Priority: 0/
Queue: CGI

People
Owner: MARKSTOS [...] cpan.org
Requestors: john.elion [...] comcast.net
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: (no value)



Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.415 (Entity 5.415)
Subject: CGI::upload returns no value
X-RT-Original-Encoding: iso-8859-1
Content-Length: 2789
Download (untitled) / with headers
text/plain 2.7k
I'm running ActiveState Perl v5.8.6(811); this bug occurred in the CGI.pm distributed with that package and I've tried upgrading to 3.07. I'm running on Windows XP Professional with an Apache 2.0 web server. I recently upgraded ActiveState Perl from the 5.6.1(628) distribution; my web site code was developed and largely debugged and had been running with that version; the upgrade was to take advantage of new "alrm" functionality to implement timeouts; upload file code was unaffected, and as the feature is rarely used the loss of functionality was not noticed. I BELIEVE this is the event at which file upload stopped working. My "upload file" web page has stopped working: the call "$query->upload('filefield') fails on an argument that is a proper upload file form element; the return value appears to be "undef". Previously, the code had apparently been reliable, as the code was quickly developed and the upload call had no error checking before calling binmode on the return value. The error was first observed when the binmode call failed (couldn't be called on an undefined value). I traced the problem into CGI.pm by inserting `echo` statements inside both CGI.pm and my web page server routines. I discovered that during my "$query = new CGI" call at the start of the server web page processing, code passes into a subroutine called "read_multipart"; and very near the end of the subroutine (the "push" statement at line 3343), the $filehandle argument contained a valid fileno. However, when "$query->upload('arg') was called, the filehandle appeared to no longer be valid. I identified the destructor "DESTROY" and at line 3433 inserted an `echo` statement merely identifying that the code was executed; I placed another statement at the line following the "$query = new CGI" subroutine. I discovered that the destructor fired prior to the exit of read_multipart; I suspect it fires when "$filename" goes out of scope in "read_multipart". The destructor did fire at some point later, but I was surprised because it appears that the filehandle needed by the "upload" routine is closed before my web page gets the original CGI handle. As a workaround, I commented out the "close" statement in the DESTROY routine at line 3433; however, this leaves temporary files and would not be practical for a web site with any volume of uploads. This made my web page start working again. I do not have a simple, extractable "file upload" page, but the code is a very basic form with the proper multipart/form-data encoding, an input of type FILE, and a POST routine that calls "new CGI" and then "CGI::upload" on the form field. If I am able I will produce a code snippet, but I hope there is enough detail (and specific version information) to reproduce the problem.
MIME-Version: 1.0
X-Mailer: MIME-tools 5.418 (Entity 5.418)
Content-Disposition: inline
Message-Id: <rt-3.6.HEAD-25596-1163262402-1118.11873-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf8"
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Original-Encoding: utf-8
Content-Length: 3508
Download (untitled) / with headers
text/plain 3.4k
On Mon Mar 14 23:12:14 2005, guest wrote: Show quoted text
> I'm running ActiveState Perl v5.8.6(811); this bug occurred in the > CGI.pm distributed with that package and I've tried upgrading to > 3.07. I'm running on Windows XP Professional with an Apache 2.0 > web server. > > I recently upgraded ActiveState Perl from the 5.6.1(628) distribution; > my web site code was developed and largely debugged and had been > running with that version; the upgrade was to take advantage of new > "alrm" functionality to implement timeouts; upload file code was > unaffected, and as the feature is rarely used the loss of > functionality was not noticed. I BELIEVE this is the event at > which file upload stopped working. > > My "upload file" web page has stopped working: the call "$query-
> >upload('filefield') fails on an argument that is a proper upload
> file form element; the return value appears to be "undef". > Previously, the code had apparently been reliable, as the code was > quickly developed and the upload call had no error checking before > calling binmode on the return value. The error was first observed > when the binmode call failed (couldn't be called on an undefined > value). > > I traced the problem into CGI.pm by inserting `echo` statements inside > both CGI.pm and my web page server routines. I discovered that > during my "$query = new CGI" call at the start of the server web > page processing, code passes into a subroutine called > "read_multipart"; and very near the end of the subroutine (the > "push" statement at line 3343), the $filehandle argument contained > a valid fileno. However, when "$query->upload('arg') was called, > the filehandle appeared to no longer be valid. > > I identified the destructor "DESTROY" and at line 3433 inserted an > `echo` statement merely identifying that the code was executed; I > placed another statement at the line following the "$query = new > CGI" subroutine. I discovered that the destructor fired prior to > the exit of read_multipart; I suspect it fires when "$filename" > goes out of scope in "read_multipart". The destructor did fire at > some point later, but I was surprised because it appears that the > filehandle needed by the "upload" routine is closed before my web > page gets the original CGI handle. > > As a workaround, I commented out the "close" statement in the DESTROY > routine at line 3433; however, this leaves temporary files and > would not be practical for a web site with any volume of uploads. > This made my web page start working again. > > I do not have a simple, extractable "file upload" page, but the code > is a very basic form with the proper multipart/form-data encoding, > an input of type FILE, and a POST routine that calls "new CGI" and > then "CGI::upload" on the form field. If I am able I will produce > a code snippet, but I hope there is enough detail (and specific > version information) to reproduce the problem.
John, Thanks for the report. CGI.pm 3.25 includes a test script for file uploading (t/upload.t). See if it passes for you, or if you can add additional test which fails as you describe. Also, I'm about to submit a patch for a bug where file handles were not reset when CGI->new() is called more than once. If you happen to be experiencing that bug, the workaround would be to call seek($fh,0,0); Just after: $fh = $q->upload('field'); Mark
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Charset: utf8
Content-Type: text/plain
Message-ID: <rt-3.6.HEAD-6413-1248308955-1450.11873-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 93
I'm considering this bug rejected now due to lack of follow-up from the reporter since 2006.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.