File upload problem
Hi,
I'm have been running mod_perl for a while now.
Current situation is:
-Win 2000 SP2
-Apache 2.0.47
-mod_perl 1.999.22
-Perl 5.8.3
http conf:
Alias /mod_perl/ "C:/Program Files/Apache Group/Apache2/mod_perl/"
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions -ParseHeaders
Options +ExecCGI
But all of the sudden I'm having problems with the file uploads from a form.
In the error.log file I find:
CGI open of tmpfile: No such file or directory
Note that those same forms gave no trouble before.
Don't know what switch did create the error.
My guess it is the installation of Perl5.8.3 (from a 5.8.1 version) and its
accompagning CGI v3.01.
Have also tried with the lastest 3.08 CGI module from CPAN
I have reduced the error to the following form and its brother mod_perl
script.
Note also that the script is running OK when placed in the cgi-bin folder
(no mod_perl). I know that is not a guarantee that it should work under
mod_perl, but still it is a nice indication.
Form
http://www.w3.org/1999/xhtml"; lang="en">
Upload Test
Upload:
Script
==
#!C:\Perl\bin\perl.exe
use CGI;
my $q = CGI->new();
print $q->header, $q->start_html('result'),$q->h1('the uploaded file');
my $filename = $q->upload('file');
print $q->p("filename: $filename");
print $q->p("content:");
print "";
while (<$filename>) { print; }
print "";
print $q->end_html;
Kind Regards
Bart Terryn
RE: File upload problem
Hi everybody
It turned out to be a CGI.pm problem related to the setup I'm running.
And here is the solution:
Apparantly CGI.pm V3.01 no longer allows you to force your TMPDIRECTORY to a
folder of your choice.
This used to be possible by uncommenting line 26 to read something like:
$CGITempFile::TMPDIRECTORY = 'C:/Temp';
But in the find_tempdir routine this was ignored by line 3753:
undef $TMPDIRECTORY;
I filed a request to the CGI.pm buglist to change this to the old behaviour.
Sorry if you feel this was not a mod_perl issue, but I was sidetracked by
the fact that this problem only occurred under the mod_perl environment.
But all is bright and shining again
Bart
-Original Message-
From: Bart Terryn [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 30, 2005 11:42 AM
To: modperl@perl.apache.org
Subject: File upload problem
Hi,
I'm have been running mod_perl for a while now.
Current situation is:
-Win 2000 SP2
-Apache 2.0.47
-mod_perl 1.999.22
-Perl 5.8.3
http conf:
Alias /mod_perl/ "C:/Program Files/Apache Group/Apache2/mod_perl/"
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions -ParseHeaders
Options +ExecCGI
But all of the sudden I'm having problems with the file uploads from a form.
In the error.log file I find:
CGI open of tmpfile: No such file or directory
Note that those same forms gave no trouble before.
Don't know what switch did create the error.
My guess it is the installation of Perl5.8.3 (from a 5.8.1 version) and its
accompagning CGI v3.01.
Have also tried with the lastest 3.08 CGI module from CPAN
I have reduced the error to the following form and its brother mod_perl
script.
Note also that the script is running OK when placed in the cgi-bin folder
(no mod_perl). I know that is not a guarantee that it should work under
mod_perl, but still it is a nice indication.
Form
http://www.w3.org/1999/xhtml"; lang="en">
Upload Test
Upload:
Script
==
#!C:\Perl\bin\perl.exe
use CGI;
my $q = CGI->new();
print $q->header, $q->start_html('result'),$q->h1('the uploaded file');
my $filename = $q->upload('file');
print $q->p("filename: $filename");
print $q->p("content:");
print "";
while (<$filename>) { print; }
print "";
print $q->end_html;
Kind Regards
Bart Terryn
Code fix/suggestion after MP2 update
Folks,
I hope my brain is just not functioning properly
yet as its Saturday, but I'm having a tough time figuring out the best way to
handle the needed changed of "Apache::*" to "Apache2::Const*"
automatically so I don't have to edit anything with a script going up on 2
different servers with 2 the 2 different MP2 installs.
The code that was effected for me was simple
enough, all my handler's are just:
sub handler { $r = shift;
my $request_type = anything
if ($request_type eq 'Apache::REDIRECT')
{ $r->headers_out->set(Location =>
$back_url); #return Apache2::Const::REDIRECT;
# or
return Apache::REDIRECT; } else
{ #return Apache::OK;
# or
return Apache2::Const::OK; }
}
I thought it would be nice and easy to do it with a PerlSetVar in the conf
file, so I would have something like
in conf:
PerlSetVar ApacheReturnRedirect Apache::REDIRECT
PerlSet
In handler
if ($request_type eq 'Apache::REDIRECT')
{ $r->headers_out->set(Location =>
$back_url); return
$r->dir_config->get('ApacheReturnRedirect'); } else
{ return
$r->dir_config->get('ApacheReturnOk'); }
But that didn't work, got an error of Argument "Apache::REDIRECT" isn't
numeric, I also can't do it within any sort of "if" statement in the script
itself as I will get the error of "Apache::* not allowed while script
subs...".
Any suggestions?
Thanks In Advance!
-Chris
Re: Code fix/suggestion after MP2 update
cfaust-dougot wrote:
Folks,
I hope my brain is just not functioning properly yet as its Saturday, but I'm having a tough time figuring out the best way to handle the needed changed of "Apache::*" to "Apache2::Const*" automatically so I don't have to edit anything with a script going up on 2 different servers with 2 the 2 different MP2 installs.
The code that was effected for me was simple enough, all my handler's are just:
sub handler {
$r = shift;
my $request_type = anything
if ($request_type eq 'Apache::REDIRECT') {
$r->headers_out->set(Location => $back_url);
#return Apache2::Const::REDIRECT;
# or
return Apache::REDIRECT;
} else {
#return Apache::OK;
# or
return Apache2::Const::OK;
}
}
I thought it would be nice and easy to do it with a PerlSetVar in the conf file, so I would have something like
in conf:
PerlSetVar ApacheReturnRedirect Apache::REDIRECT
PerlSet
In handler
if ($request_type eq 'Apache::REDIRECT') {
$r->headers_out->set(Location => $back_url);
return $r->dir_config->get('ApacheReturnRedirect');
} else {
return $r->dir_config->get('ApacheReturnOk');
}
But that didn't work, got an error of Argument "Apache::REDIRECT" isn't numeric, I also can't do it within any sort of "if" statement in the script itself as I will get the error of "Apache::* not allowed while script subs...".
Any suggestions?
That's funky :) But you can't do that. Since those constants are really
subroutines. What you are returning are strings, so you will need to eval
those before using those. The best run the script that will adjust the
constants: http://people.apache.org/~geoff/fixme
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: for a background process and return
jiesheng zhang wrote:
Hi
I am try to run something like this in my cgi.
-
system ("sleep 3000 &");
---
Since, it is time-consuming task, I let it run in background and
immediately return to user. I tested this script. It was no problem for
a standalone perl script. However, once I had this script in a perl cgi.
The script seemed not to have this system command run in background. It
waited there for the child process to finish.
Any clue for why it behaved like that? How can I for a child process in
background and return immediately to the web user?
Help is really appreciated!
jiesheng, please take a look at:
http://perl.apache.org/docs/1.0/guide/performance.html#Forking_and_Executing_Subprocesses_from_mod_perl
it explains how to do this sort of things.
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: changing permissions in order to write a file in Mod_perl
Dermot Paikkos wrote: I really don't know but I was just trying to set up something similar here and noticed that under MP1 you certainly couldn't, see this article: http://perl.apache.org/docs/1.0/guide/install.html#Is_it_possible_to_r un_mod_perl_enabled_Apache_as_suExec_ And then I saw this on changes on MP2: "perchild The perchild MPM is similar to the worker MPM, but is extended with a mechanism which allows mapping of requests to virtual hosts to a process running under the user id and group configured for that host. This provides a robust replacement for the suexec mechanism. META: as of this writing this mpm is not working" It still doesn't. Though there is metux: http://www.metux.de/mpm/ which is in works. It looks like suexec is not an option. There maybe an alternitive in the future though. Perhaps someone else with more knowledge on MP could answer your question better than I can. That's right. As explained in link Dermot has quoted above, suexec doesn't and won't work under mod_perl (no matter what the version) -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: advice needed: mod_perl reverse proxy
hi stas
Stas Bekman wrote:
allan juul wrote:
[...]
But if you use a mod_perl filter you will still hit the issue of
unknown content-length header.
yes, of course that's true.
there goes caching (:
Not really. Nothing prevents you from buffering up the response, process
it, set the content-length header and make the document cache-able.
ok, eh how do i that. you mean instead of printing to STDOUT, collect
data in a buffer, then set the calculated Content-Length, then print data?
anyway, it's pretty strange. it seems i'm able to set the Content-Length
when i use the mod_perl_filter and do *not* reverse proxy. see both
headers below. the strange things is that i'm not allowed at all to set
the standard Content-Length, but indeed allowed to set a custom one
called Content-Length2. and even stranger is that this custom header
presents a correct value when *not* proxying but "0" when proxying. i
use the exact same mod_perl code, also supplied below. the actual
filtering of data content works in both cases.
all this is on windows.
./allan
# CODE ##
# this is heavily based on
# http://search.cpan.org/~geoff/Apache-Clean-2.00_7/
package Apache::Clean;
use 5.008;
use Apache2::Filter ();
use Apache2::RequestRec ();
use Apache2::RequestUtil ();
use Apache2::Log ();
use APR::Table ();
use Apache2::Const -compile => qw(OK DECLINED);
use strict;
sub handler {
my $f = shift;
my $r = $f->r;
my $log = $r->server->log;
unless ($r->content_type =~ m!text/html!i) {
$log->info('skipping request to ', $r->uri, ' (not an HTML
document)');
return Apache2::DECLINED;
}
my $context;
unless ($f->ctx) {
$r->headers_out->unset('Content-Length');
}
$context ||= $f->ctx;
my $content_length = 0;
while ($f->read(my $buffer, 1024)) {
$buffer = $context->{extra} . $buffer if $context->{extra};
if (($context->{extra}) = $buffer =~ m/(<[^>]*)$/) {
$buffer = substr($buffer, 0, - length($context->{extra}));
}
my $str = $buffer;
$str =~ s,OLD,NEW,igs;
$content_length += length( $str );
$f->print( ${str} );
}
if ($f->seen_eos) {
$f->print($context->{extra}) if $context->{extra};
$content_length += length( $context->{extra} );
}
else {
$f->ctx($context);
}
$r->headers_out->set('Content-Length', $content_length);
$r->headers_out->set('Content-Length2', $content_length);
return Apache2::OK;
}
1;
# HEADERS ##
# no rev proxy
$ head localhost
200 OK
Connection: close
Date: Sat, 30 Apr 2005 20:02:17 GMT
Accept-Ranges: bytes
Server: Apache/2.0.54 (Win32) mod_ssl/2.0.53 OpenSSL/0.9.7f
proxy_html/2.4 mod_perl/1.999.22-dev Perl/v5.8.6
Vary: negotiate,accept-language,accept-charset
Content-Language: en
Content-Length: 1773
Content-Location: index.html.en
Content-Type: text/html
Last-Modified: Sun, 21 Nov 2004 05:35:22 GMT
Client-Date: Sat, 30 Apr 2005 20:02:17 GMT
Client-Peer: 127.0.0.1:80
Client-Response-Num: 1
Content-Length2: 1773
# with rev proxy
$ head localhost
200 OK
Cache-Control: no-cache, no-store
Connection: close
Date: Sat, 30 Apr 2005 20:04:24 GMT
Pragma: no-cache
Server: Microsoft-IIS/6.0
Content-Type: text/html; charset=utf-8
Expires: -1
Client-Date: Sat, 30 Apr 2005 20:04:25 GMT
Client-Peer: 127.0.0.1:80
Client-Response-Num: 1
Content-Length2: 0
Set-Cookie: ASP.NET_SessionId=4nddnr453tjk0355flblp3fg; path=/
X-AspNet-Version: 1.1.4322
X-Powered-By: ASP.NET
Mod_perl upload problem
Hi,
I'm have been running mod_perl for a while now.
Current situation is:
-Win 2000 SP2
-Apache 2.0.47
-mod_perl 1.999.22
-Perl 5.8.3
http conf:
Alias /mod_perl/ "C:/Program Files/Apache Group/Apache2/mod_perl/"
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions -ParseHeaders
Options +ExecCGI
But all of the sudden I'm having problems with the file uploads from a form.
In the error.log file I find:
CGI open of tmpfile: No such file or directory
Note that those same forms gave no trouble before.
Don't know what switch did create the error.
My guess it is the installation of Perl5.8.3 (from a 5.8.1 version) and its
accompagning CGI v3.01.
Have also tried with the lastest 3.08 CGI module from CPAN
I have reduced the error to the following form and its brother mod_perl
script.
Note also that the script is running OK when placed in the cgi-bin folder
(no mod_perl). I know that is not a guarantee that it should work under
mod_perl, but still it is a nice indication.
Form
http://www.w3.org/1999/xhtml"; lang="en">
Upload Test
Upload:
Script
==
#!C:\Perl\bin\perl.exe
use CGI;
my $q = CGI->new();
print $q->header, $q->start_html('result'),$q->h1('the uploaded file');
my $filename = $q->upload('file');
print $q->p("filename: $filename");
print $q->p("content:");
print "";
while (<$filename>) { print; }
print "";
print $q->end_html;
RE: Code fix/suggestion after MP2 update
Title: Re: Code fix/suggestion after MP2 update
cfaust-dougot wrote:>>>
Folks,>>> >>> I hope my brain is just not
functioning properly yet as its Saturday, but I'm having a tough time figuring
out the best way to handle the needed changed of "Apache::*" to
"Apache2::Const*" automatically so I don't have to edit anything with a script
going up on 2 different servers with 2 the 2 different MP2
installs.>>> >>> The code that was effected for
me was simple enough, all my handler's are
just:>>> >>> >>> sub handler
{> >> $r = shift;> >
my $request_type = anything>>> >>> if
($request_type eq 'Apache::REDIRECT') {>>>
$r->headers_out->set(Location =>
$back_url);>>> #return
Apache2::Const::REDIRECT;>>> #
or>>> return
Apache::REDIRECT;>>> } else {>>>
#return Apache::OK;>>> # or>>>
return Apache2::Const::OK;>>>
}>>> >>> }>>> >>>
I thought it would be nice and easy to do it with a PerlSetVar in the conf file,
so I would have something like>>> >>> in
conf:>>> PerlSetVar ApacheReturnRedirect
Apache::REDIRECT>>>
PerlSet>>> >>> In
handler>>> if ($request_type eq 'Apache::REDIRECT')
{>>> $r->headers_out->set(Location =>
$back_url);> >> return
$r->dir_config->get('ApacheReturnRedirect');>>> }
else {>>> return
$r->dir_config->get('ApacheReturnOk');>>>
}>> But that didn't work, got an error of Argument
"Apache::REDIRECT" isn't numeric, I also can't do it within any sort of "if"
statement in the script itself as I will get the error of "Apache::* not allowed
while script subs...".> > Any
suggestions?>That's funky :) But you can't do that. Since those
constants are really>subroutines. What you are returning are strings, so
you will need to eval>those before using those. The best run the script
that will adjust the>constants: http://people.apache.org/~geoff/fixme
Thanks Stas, I was hoping to avoid any sort of
preprocessing but if that's what it takes so you guys can keep producing
lighting in a bottle, I'm not going to complain.
-Chris
Re: Code fix/suggestion after MP2 update
cfaust-dougot wrote:
return $r->dir_config->get('ApacheReturnOk');
}
But that didn't work, got an error of Argument "Apache::REDIRECT" isn't numeric, I also can't do it
within any sort of "if" statement in the script itself as I will get the error of "Apache::*
not allowed while script subs...".
Any suggestions?
That's funky :) But you can't do that. Since those constants are really
subroutines. What you are returning are strings, so you will need to eval
those before using those. The best run the script that will adjust the
constants: http://people.apache.org/~geoff/fixme
Thanks Stas, I was hoping to avoid any sort of preprocessing but if
that's what it takes so you guys can keep producing lighting in a
bottle, I'm not going to complain.
Why preprocessing? Just replace those with Apache::Const::OK or whatever
is needed. See the fixme script above.
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
