Apache 2.0.47, modperl 1.99.09 and CGI::Simple -- file uploads not working
Hello all,
I'm working on a site under Apache 2.0.47 with modperl 1.99.09. I've got
most everything working right in my server setup, I can get and set
cookies, get input variables from forms/etc., and all that jazz. I'm
having a problem with form uploads however.
Here's a test script/form and the output:
FORM
SCRIPT
#!/usr/bin/perl -w
use CGI::Simple;
use strict;
my $query = new CGI::Simple;
my $files = $query->upload();
my @files = $query->upload();
my $filename = $query->param('upload_file');
my $size = $query->upload_info($filename, 'size');
my $mime = $query->upload_info($filename, 'mime');
print "Content-Type: text/plain\n\n";
print "upload() as scalar: ", $files, "\n";
print "upload() as list: ", join(', ', @files), "\n";
print "param('upload_file'): ", $filename, "\n";
print "upload_info(..., 'size'): ", $size, "\n";
print "upload_info(..., 'mime'): ", $mime, "\n";
exit;
---
RESULTS
---
upload() as scalar:
upload() as list:
param('upload_file'): ancient_wisdom.jpg
upload_info(..., 'size'):
upload_info(..., 'mime'):
---
Is there a reason the uploaded file isn't coming through. I'd be more
specific if I knew what the cause might be, but I'm just at a loss.
CGI::Simple v0.071
Perl 5.8.0
Thanks in advance,
Jacob Fugal
Re: Apache 2.0.47, modperl 1.99.09 and CGI::Simple -- file uploads not working
Ok, everyone, sorry to have bothered you with this. Turns out it didn't have anything to do with modperl or apache, but that I was just missing some stuff from CGI::Simple. By default, CGI.pm (which I was used to) enables file uploads of unlimited size; by contrast CGI::Simple's default is to disable file uploads. It's even in the man page. I guess I must have glossed past that part somehow. My apologies for taking up your time. Jacob Fugal (Stas: I didn't file a bug report, since from the beginning I thought it was a configuration issue but didn't know which, so you don't need to worry about hunting it down and canceling it)
Re: PATCH porting.pod "First Mystery"
(sorry Brian, this was supposed to go to the list... is there any plan to fix the reply-to header on this list?) Brian McCauley wrote: Stas Bekman <[EMAIL PROTECTED]> writes: ... I'd keep the "for which" even if some people consider such strict English grammar to be affected. I guess it reads better if using commas: The easiest and the fastest way to solve the nested subroutines problem is to switch every lexically scoped variable, you get the warning for, to a global package variable. OK, I still find the strict English grammar easier to read in this instance, but I'll go with your form. I know, as a newbie to the list, I probably won't have much sway in this, but I have to agree with Brian. I read the version above -- the one with commas -- and it just isn't working for me. My brain just won't parse that as correct English (or even Englilsh). If I remember my grammar correctly, you only use commas to set of a descriptive phrase when it's a noun clause (such as "my friend's cousin", "the big red one over there", etc.). Prepositional phrases should flow inline with the noun being described. That's why there're no commas. It becomes, "every lexically scoped variable you get the error for," if you're not going to mind the misuse of the preposition. I'd be fine with that under most circumstances, but the following context makes it weird, which was probably Brian's original point. Switching to correct use of the preposition, "for which", fixes that. "...switch every lexically scoped variable for which you get the warning to a..." It's not affected -- it's correct. We American's sometimes think of correct grammar as affected (myself included), but sometimes it's correct anyways and it actually makes things easier to understand. Ok, enough of my english rant, flame on :) Jacob Fugal
Re: PATCH porting.pod "First Mystery"
Geoffrey Young wrote: I know, as a newbie to the list, welcome. Thanks. in general, this list is very welcoming to newbies. so, please don't take what I'm about to say as being directed toward you... ['elements of style' excerpts snipped] you know, if y'all spent less time squibbling over minor grammatical points, and instead channeled all this free energy and tuits into augmenting the docs with new material, everyone would be better off. Agreed :) Unfortunately, I'm rather a beginner with modperl -- hence my subscription to this list -- and don't feel comfortable submitting documentation yet. But hopefully I can and will soon. Jacob
Re: New User's First Steps
Eric Moore wrote:
Having googl'd and read various faqs, cookbooks...
Site worked OK under CGI, but slowly -- on an old machine.
I have converted to mod_perl only using the Apache::Registry. Application
uses CGI::App and HTML::Template.
Site runs faster now, but warnings disappeared from all logs. [errors] show
up, but not warnings.
Any ideas on what I'm doing wrong?
Thanks, Eric.
httpd.conf
--
LogLevel warn
PerlModule Apache::Registry
...
DocumentRoot /var/www/pick6/
ServerName www.yadda.com
ServerAdmin [EMAIL PROTECTED]
ErrorLog logs/error_log
TransferLog logs/access_log
ErrorLog /var/www/logs/pick6.error_log
CustomLog /var/www/logs/pick6.access_log common
Alias /perl/ /var/www/pick6/cgi-bin/
ServerAlias yadda.com *.yadda.com
SSLEngine on
SSLCertificateFile/etc/ssl/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key
CustomLog logs/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
Have you looked in the main error log (as opposed to
/var/www/logs/pick6.error_log) for the warnings? I couldn't find my
warns for a long time until I finally thought to check there. Errors
(anything that causes an internal server error to display in the
browser) show up in the per-host log, but the warn level STDERR all
ignores the ErrorLog directive and goes to the main log. This may be
what's happening to you.
I don't know how to fix it (if anyone else on here does, please let me
know as well as Eric :), but in the meantime I just keep both error logs
open. A pain, but bearable (at least for me).
Jacob Fugal
Re: New User's First Steps
Ged Haywood wrote: Hi there, On Wed, 29 Oct 2003, Eric Moore wrote: I saw a note about redirecting STDERR to the screen but nothing about sending it to the virtual_host.error_log. Do you really want to do that? Some errors may have nothing to do with a virtual host (no permission, no more filehandles, disc full...) and are more appropriate to the main server error_log. Except these (the ones you describe) are the errors that *do* get correctly passed to the virtual host's error log via the ErrorLog directive. The ones that there are no question about wanting them to go there (warn statements in my perl code, for instance) go to the wrong/inconvenient place. Jacob Fugal
