cvs commit: modperl-2.0/ModPerl-Registry TODO
stas2003/02/04 20:06:28
Modified:.Changes
ModPerl-Registry/lib/ModPerl RegistryCooker.pm
ModPerl-Registry TODO
Log:
warn on using -T in ModPerl::Registry scripts when mod_perl is not
running with -T
Revision ChangesPath
1.122 +7 -4 modperl-2.0/Changes
Index: Changes
===
RCS file: /home/cvs/modperl-2.0/Changes,v
retrieving revision 1.121
retrieving revision 1.122
diff -u -r1.121 -r1.122
--- Changes 4 Feb 2003 06:52:15 - 1.121
+++ Changes 5 Feb 2003 04:06:27 - 1.122
@@ -10,10 +10,13 @@
=item 1.99_09-dev
-perl 5.7.3+ has a built-in ${^TAINT} to test whether running under
--(T|t). Backport ${^TAINT} for mod_perl running under 5.6.0-5.7.3,
-(what used to be $Apache::__T. $Apache::__T is available too, but
-deprecated. [Stas]
+warn on using -T in ModPerl::Registry scripts when mod_perl is not
+running with -T [Stas]
+
+perl 5.7.3+ has a built-in ${^TAINT} to test whether it's running
+under -(T|t). Backport ${^TAINT} for mod_perl running under
+5.6.0-5.7.3, (what used to be $Apache::__T. $Apache::__T is available
+too, but deprecated. [Stas]
add PerlChildExitHandler implementation [Stas]
1.30 +4 -5 modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm
Index: RegistryCooker.pm
===
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- RegistryCooker.pm 18 Jan 2003 02:04:32 - 1.29
+++ RegistryCooker.pm 5 Feb 2003 04:06:27 - 1.30
@@ -552,10 +552,9 @@
my %switches = (
'T' = sub {
-# XXX: need to have $Apache::__T set by the core on PerlSwitches -T
-# Apache::warn(T switch is ignored, ,
-#enable with 'PerlSwitches -T' in httpd.conf\n)
-# unless $Apache::__T;
+ Apache::warn(-T switch is ignored, .
+enable with 'PerlSwitches -T' in httpd.conf\n)
+ unless ${^TAINT};
;
},
'w' = sub { use warnings;\n },
@@ -574,7 +573,7 @@
last if substr($s,0,1) eq -;
for (split //, $s) {
next unless exists $switches{$_};
- $prepend .= {$switches{$_}};
+ $prepend .= $switches{$_}-();
}
}
${ $self-[CODE] } =~ s/^/$prepend/ if $prepend;
1.12 +0 -2 modperl-2.0/ModPerl-Registry/TODO
Index: TODO
===
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/TODO,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- TODO 29 Dec 2002 10:11:49 - 1.11
+++ TODO 5 Feb 2003 04:06:27 - 1.12
@@ -14,8 +14,6 @@
### missing features ###
-- need to port $Apache::__T, to test against when user supplies -T flag.
-
- port Apache::PerlRunXS
- replace the local implementation of slurp_filename() and finfo(),
Re: Possible bug with a 206 Partial Response
alrightly, back again. The problem is that Apache::Registry will return
a 206, which will trigger the error message. In case there is anyone
out there as daft as me :), the crude delegation-type module below can
solve this problem. Maniacs who see a need to return 204's, etc can
probably extend this to a more general solution. :)
package MyPrefix::Apache::Registry;
use strict;
BEGIN {
use Apache::Registry();
use Apache::Constants qw(:common);
use constant PARTIAL_CONTENT = 206;
}
sub handler {
my ($return) = Apache::Registry::handler(@_);
if ($return == PARTIAL_CONTENT) {
return OK;
} else {
return ($return);
}
}
END { }
1;
Uru
-Dave
Ged Haywood wrote:
Hi again,
On Mon, 3 Feb 2003, David Dick wrote:
not even getting a broken connection. So somehow mod_perl doesn't
_really_ think it's an error.
Check out DEBUGGING in 'perldoc Apache::Registry'.
Apache::Registry won't always return what you'd think it should.
This has snookered more than one in the past...
73,
Ged.
Problem Building 1.99_08 on OpenBSD
OpenBSD 3.2 Perl 5.6.1 I'm trying to build MP 1.99_08 for Apache 2.0.44, and I'm not quite sure where I'm messing up. Apache built fine, building the config for MP went fine: jweisen@kaitain$ sudo perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2 MP_INST_APACHE2=1 ... *** mod_perl dso library will be built as mod_perl.so *** mod_perl static library will be built as mod_perl.a *** You'll need to add the following to httpd.conf: *** LoadModule perl_module modules/mod_perl.so But the actual make doesn't go so well: jweisen@kaitain$ sudo make ... ranlib: mod_perl.so: Inappropriate file type or format *** Error code 1 Stop in /usr/local/src/mod_perl-1.99_08/src/modules/perl (line 149 of Makefile.modperl). *** Error code 1 Stop in /usr/local/src/mod_perl-1.99_08 (line 459 of Makefile). I dug back a couple months in the mailing lists and I'm not seeing anything applicable. Any help would be appreciated. Thanks, John -- John W. Eisenschmidt ([EMAIL PROTECTED]) http://www.eisenschmidt.org/jweisen/pgp.html If encryption is outlawed, then only outlaws will have encryption. msg32660/pgp0.pgp Description: PGP signature
Re[2]: cgi and mod_perl-1.26, Apache-1.27, perl-5.8.0, FreeBSD failwith 'The document contained no data'
-BEGIN PGP SIGNED MESSAGE- Hash: MD5 Hi Stas, On Tuesday, February 4, 2003 at 2:47:43 AM, you wrote: SB Lee Goddard wrote: SB [...] I don't know: you're doing this: print Content-type: text/plain\n\n; print Hello World\n; Does it (probably not) make any difference if you do a full CRLF, as perldoc perlop: For example, most networking protocols expect and prefer a CR+LF (\015\012 or \cM\cJ) for line terminators, and although they often accept just \012, they seldom tolerate just \015. If you get in the habit of using \n for networking, you may be burned some day. SB Apache already fixes up \n\n to the right thing. What it really does SB is identifying the Content-type: header, and then adds the terminating SB by itself, because it really sends other headers, before adding an SB empty new line. So it shouldn't matter if you say \r\n\r\n or just SB \n\n, unless there is a bug. So if Apache (mod_perl) adds this to his script, even though it is not a mod_perl script, then shouldn't he be calling it from a Location that isn't mod_perl enabled...? Sorry, just getting into this Apache module thing Cheers lee - -- Cheers Leemailto:[EMAIL PROTECTED] $$=qw$808273788400074285838400657879847269820080698276007265677569820727$; $$=~s$(\d\d)$\$_.=chr(\$1+32)$ge;eval; -BEGIN PGP SIGNATURE- Version: 2.6 iQCVAwUAPj+AYqdrfekeF/QBAQErkgQApGgGWv78D4in/2NmcoBTqMPdKKyYUZia ZN7chLUcduSoyqftj70iU0+PCAheJqX6k+9Q/bErraOoP4g3S5aMW99zYMLfXKtx XhTHhusNkroSGKpyXI7FlyKOaQqDLN+S8vm5QAlEkZlK6ZfgovgevSnCqfsiuc48 /EW2drjX1w0= =Ef7H -END PGP SIGNATURE-
Apache::Registry incompatible with CGI ?
Hi,
I have written a request handler in Perl. I recently changed some code
in this to convert
from using CGI within mod_perl to using Apache::Registry. The old code
was ...
$DB-{ApacheReq} = shift;
:
$DB-{Page} = CGI::new();
:
The new code is ...
:
$DB-{ApacheReq}= Apache::Request-new(shift);
:
$DB-SetupPageArguments();
:
sub SetupPageArguments()
{
my ($DB, $nLoop, @Query, $Key, $Value);
$DB=shift;
@{$DB-{Page}-{'.parameters'}}=$DB-{ApacheReq}-param();
for($nLoop=0; $nLoop=$#{$DB-{Page}-{'.parameters'}}; $nLoop++)
{
if(!defined($DB-{ApacheReq}-param($DB-{Page}-{'.parameters'}[$nLoop]
)))
{
$DB-{Page}-{$DB-{Page}-{'.parameters'}[$nLoop]}[0]='';
}
else
{
@{$DB-{Page}-{$DB-{Page}-{'.parameters'}[$nLoop]}}=$DB-{ApacheReq}-
param($DB-{Page}-{'.parameters'}[$nLoop]);
}
}
}
My handler then referes to the '.parameters' field and the arrays of
values. For most posts
this works fine. However, when I send a large block of data in with the
request I have found
that portions of the middle are left out. Putting the old code back
means that the whole of the
text is seen.
I am using a client program written in C++ to send the requests in. All
requests are sent as a
multipart message, with each form field having one part within the
message. On the particular
instance I have been looking at the overall content size for the request
(excluding the header)
in my application is set to 21555. (I have not set the flag to limit
post size as you can see
from the above). The end of the request appears as ...
:
:
:
function NewProductExtension(Id, ExtensionId, Description, MinRequired,
MaxRequired, Visible, WarnLessThan, WarnGreaterThan, LessThanWarning,
GreaterThanWarning, Width, Units)\n{\n new ProductExtension(Id,
ExtensionId, Description, MinRequired, MaxRequired, Visible,
WarnLessThan, WarnGreaterTha*ion CheckProductExtensions()
{
var nLoop;
var Rc=new String('');
for(nLoop=0; nLoopProducts.length; nLoop++)
{
if(Products[nLoop].ExtensionCountProducts[nLoop].Extensions.length)
{
Rc=Rc+(Products[nLoop].ProductId+',');
}
}
Rc=Rc.substr(0, Rc.length-1);
return(Rc);
}
where * denotes the portion that is missing (about 100 lines
or so)
I also sometimes see spurious data added after the request.
My server is running linux 2.4.18 on a two-way Intel box. I have Apache
1.3.26 / mod_perl 1.27
I downloaded Apache::Registry from CPAN and I have version 2.01. My C
compiler is gcc 2.96
I have not been able to run a LAN trace to see what's being sent, but
since it is OK with CGI I
assume that I am sending what my client says I'm sending.
Unfortunately I do not understand how the C / Perl and XS files all
stitch together so my attempts
to look at the code have not been fruitful.
I have adopted some code that works neatly under the Apache::Registry
but will have to be fudged to work with CGI so I am keen to get this
working.
Can anyone help ?
Rob Lambden
Security Concern, massive CGI or Headers problems?
I, rather blindly, put a reference to a hash of the HTTP headers and hash of
the CGI params in pnotes for most requests.
Technically, a poorly formed loop might DOS a child if the number of params
or headers is evilly large.
For instance, someone silly could write
my $params = $r-pnotes('params');
foreach my $key_1 (keys %$params) {
foreach my $key_2 (keys %$params) {
next if $key_1 eq $key_2;
warn duplicate message from $key_1 and $key_2 if $params-{$key_1} eq
$params-{$key_2}
}
}
Of course that's silly code, but, looping over the params or headers is
certainly not an impossibility.
Do I need to, should I do any checks before stashing these values in pnotes?
Thx
--
This message is intended only for the personal and confidential use of the designated
recipient(s) named above. If you are not the intended recipient of this message you
are hereby notified that any review, dissemination, distribution or copying of this
message is strictly prohibited. This communication is for information purposes only
and should not be regarded as an offer to sell or as a solicitation of an offer to buy
any financial product, an official confirmation of any transaction, or as an official
statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or
error-free. Therefore, we do not represent that this information is complete or
accurate and it should not be relied upon as such. All information is subject to
change without notice.
Re: Apache::Registry incompatible with CGI ?
Hi there, On Tue, 4 Feb 2003, Rob Lambden wrote: I have written a request handler in Perl. I recently changed some code in this to convert from using CGI within mod_perl to using Apache::Registry. It's generally best to write handlers. If you have written a handler, in general I think you should stay with it. The Apache::Registry handler is really a kludge to get legacy scripts going and it isn't intended that you would use it for new code. There are lots of things to think about (including traps for the unwary:), and a great deal of documentation in the mod_perl Guide to help you. 73, Ged.
Re: Apache::Registry incompatible with CGI ?
Rob Lambden wrote:
sub SetupPageArguments()
{
my ($DB, $nLoop, @Query, $Key, $Value);
$DB=shift;
@{$DB-{Page}-{'.parameters'}}=$DB-{ApacheReq}-param();
for($nLoop=0; $nLoop=$#{$DB-{Page}-{'.parameters'}}; $nLoop++)
{
if(!defined($DB-{ApacheReq}-param($DB-{Page}-{'.parameters'}[$nLoop]
)))
{
$DB-{Page}-{$DB-{Page}-{'.parameters'}[$nLoop]}[0]='';
}
else
{
@{$DB-{Page}-{$DB-{Page}-{'.parameters'}[$nLoop]}}=$DB-{ApacheReq}-
param($DB-{Page}-{'.parameters'}[$nLoop]);
}
}
What's the purpose of that loop? Is it just to copy the data out of
Apache::Request/CGI? I would do something a little more compact, like this:
my @keys = $DB-{ApacheReq}-param();
my %param_hash = map { $_, [ $DB-{ApacheReq}-param($_) ] } @keys;
$DB-{Page} = \%param_hash;
$DB-{Page}-{'.parameters'} = \@keys;
However, when I send a large block of data in with the
request I have found
that portions of the middle are left out. Putting the old code back
means that the whole of the
text is seen.
Have you tried debugging the individual parameters to see exactly which
ones(s) are getting munged? Print them out in both versions and compare
them to see where the data is being lost.
- Perrin
Re: cgi and mod_perl-1.26, Apache-1.27, perl-5.8.0, FreeBSD failwith 'The document contained no data'
Hi guys, Thanks for your replies. Problem still not solved but I'll let you know if I find an answer. George. Lee Goddard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: MD5 Hi Stas, On Tuesday, February 4, 2003 at 2:47:43 AM, you wrote: SB Lee Goddard wrote: SB [...] I don't know: you're doing this: print Content-type: text/plain\n\n; print Hello World\n; Does it (probably not) make any difference if you do a full CRLF, as perldoc perlop: For example, most networking protocols expect and prefer a CR+LF (\015\012 or \cM\cJ) for line terminators, and although they often accept just \012, they seldom tolerate just \015. If you get in the habit of using \n for networking, you may be burned some day. SB Apache already fixes up \n\n to the right thing. What it really does SB is identifying the Content-type: header, and then adds the terminating SB by itself, because it really sends other headers, before adding an SB empty new line. So it shouldn't matter if you say \r\n\r\n or just SB \n\n, unless there is a bug. So if Apache (mod_perl) adds this to his script, even though it is not a mod_perl script, then shouldn't he be calling it from a Location that isn't mod_perl enabled...? Sorry, just getting into this Apache module thing Cheers lee - -- Cheers Leemailto:[EMAIL PROTECTED] $$=qw$808273788400074285838400657879847269820080698276007265677569820727$; $$=~s$(\d\d)$\$_.=chr(\$1+32)$ge;eval; -BEGIN PGP SIGNATURE- Version: 2.6 iQCVAwUAPj+AYqdrfekeF/QBAQErkgQApGgGWv78D4in/2NmcoBTqMPdKKyYUZia ZN7chLUcduSoyqftj70iU0+PCAheJqX6k+9Q/bErraOoP4g3S5aMW99zYMLfXKtx XhTHhusNkroSGKpyXI7FlyKOaQqDLN+S8vm5QAlEkZlK6ZfgovgevSnCqfsiuc48 /EW2drjX1w0= =Ef7H -END PGP SIGNATURE- -- 7, College View, Cirencester, Gloucestershire, GL7 1WD, UK 07957 141204 [EMAIL PROTECTED]
Apache::Request incompatible with CGI ?
(Originally posted as Apache::Registry incompatible with CGI? by mistake
- sorry !)
Hi,
I have written a request handler in Perl. I recently changed some code
in this to convert
from using CGI within mod_perl to using Apache::Request. The old code
was ...
$DB-{ApacheReq} = shift;
:
$DB-{Page} = CGI::new();
:
The new code is ...
:
$DB-{ApacheReq}= Apache::Request-new(shift);
:
$DB-SetupPageArguments();
:
sub SetupPageArguments()
{
my ($DB, $nLoop, @Query, $Key, $Value);
$DB=shift;
@{$DB-{Page}-{'.parameters'}}=$DB-{ApacheReq}-param();
for($nLoop=0; $nLoop=$#{$DB-{Page}-{'.parameters'}}; $nLoop++)
{
if(!defined($DB-{ApacheReq}-param($DB-{Page}-{'.parameters'}[$nLoop]
)))
{
$DB-{Page}-{$DB-{Page}-{'.parameters'}[$nLoop]}[0]='';
}
else
{
@{$DB-{Page}-{$DB-{Page}-{'.parameters'}[$nLoop]}}=$DB-{ApacheReq}-
param($DB-{Page}-{'.parameters'}[$nLoop]);
}
}
}
My handler then referes to the '.parameters' field and the arrays of
values. For most posts
this works fine. However, when I send a large block of data in with the
request I have found
that portions of the middle are left out. Putting the old code back
means that the whole of the
text is seen.
I am using a client program written in C++ to send the requests in. All
requests are sent as a
multipart message, with each form field having one part within the
message. On the particular
instance I have been looking at the overall content size for the request
(excluding the header)
in my application is set to 21555. (I have not set the flag to limit
post size as you can see
from the above). The end of the request appears as follows (This request
happens to conatin
Javascript, but the content should be irrelevant as it has not been
processed by anything at
this stage) ...
:
:
:
function NewProductExtension(Id, ExtensionId, Description, MinRequired,
MaxRequired, Visible, WarnLessThan, WarnGreaterThan, LessThanWarning,
GreaterThanWarning, Width, Units)\n{\n new ProductExtension(Id,
ExtensionId, Description, MinRequired, MaxRequired, Visible,
WarnLessThan, WarnGreaterTha*ion CheckProductExtensions()
{
var nLoop;
var Rc=new String('');
for(nLoop=0; nLoopProducts.length; nLoop++)
{
if(Products[nLoop].ExtensionCountProducts[nLoop].Extensions.length)
{
Rc=Rc+(Products[nLoop].ProductId+',');
}
}
Rc=Rc.substr(0, Rc.length-1);
return(Rc);
}
where * denotes the portion that is missing (about 100 lines
or so)
I also sometimes see spurious data added after the request.
My server is running linux 2.4.18 on a two-way Intel box. I have Apache
1.3.26 / mod_perl 1.27
I downloaded Apache::Request from CPAN and I have version 0.31. My C
compiler is gcc 2.96
I have not been able to run a LAN trace to see what's being sent, but
since it is OK with CGI.pm I
assume that I am sending what my client says I'm sending.
Unfortunately I do not understand how the C / Perl and XS files all
stitch together so my attempts
to look at the code have not been fruitful.
I have adopted some code that works neatly under the Apache::Request but
will have to be fudged to
work with CGI so I am keen to get this working.
Can anyone help ?
Rob Lambden
RE: Apache::Registry incompatible with CGI ?
Perrin Hawkins wrote:
What's the purpose of that loop?
I am setting up an array in $DB-{Page}-{'.parameters'}[...] with each
entry
being the name of a parameter sent by the client. I am then setting up
an array
for each of these parameters in $DB-{Page}-{ParameterName}[...] with
one value
for each submitted argument (so if UserName is sent more than once I
will end up
with a $DB-{Page}-{UserName} array with one value for each submitted
argument.
It should also set up file Apache::Upload objects for posted files (so
I'm told).
I would do something a little more compact, like this:
Thanks for the suggestion - I will look at this. My background is C/C++
and I'm
carefull about writing code that I understand in the future !
Have you tried debugging the individual parameters to see exactly which
ones(s) are getting munged?
It's the long submissions that are munged. I have not had a chance to
investigate
exactly where the problem happens yet. Since the original code worked
(simply
using:
$DB-{Page} = CGI::new();
) it is clear that the submission to the Apache server works, but the
return value
from the param call is missing out some of the data. As I mentioned in
the original
post I'm not clear on how the C / XS and perl files fit together so my
attempts to
debug the code did not get very far.
Regards
Rob Lambden
Re: cgi and mod_perl-1.26, Apache-1.27, perl-5.8.0, FreeBSD failwith 'The document contained no data'
Lee Goddard wrote: I don't know: you're doing this: print Content-type: text/plain\n\n; print Hello World\n; Does it (probably not) make any difference if you do a full CRLF, as perldoc perlop: For example, most networking protocols expect and prefer a CR+LF (\015\012 or \cM\cJ) for line terminators, and although they often accept just \012, they seldom tolerate just \015. If you get in the habit of using \n for networking, you may be burned some day. SB Apache already fixes up \n\n to the right thing. What it really does SB is identifying the Content-type: header, and then adds the terminating SB by itself, because it really sends other headers, before adding an SB empty new line. So it shouldn't matter if you say \r\n\r\n or just SB \n\n, unless there is a bug. So if Apache (mod_perl) adds this to his script, even though it is not a mod_perl script, then shouldn't he be calling it from a Location that isn't mod_perl enabled...? Sorry, just getting into this Apache module thing The script sends the header, which could be multiline and terminates it with an empty new line. By saying 'PerlSendHeader On' you tell mod_perl to parse the headers (which is actually done by an apache functions) and separate them from the body. Apache then adds other headers (Server token, Date, etc) and sends the response as if it was a mod_perl module. Think of Apache::Registry and friends as mod_cgi on mushrooms. __ 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: Problem Building 1.99_08 on OpenBSD
John Eisenschmidt wrote: OpenBSD 3.2 Perl 5.6.1 I'm trying to build MP 1.99_08 for Apache 2.0.44, and I'm not quite sure where I'm messing up. Apache built fine, building the config for MP went fine: jweisen@kaitain$ sudo perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2 MP_INST_APACHE2=1 ... *** mod_perl dso library will be built as mod_perl.so *** mod_perl static library will be built as mod_perl.a *** You'll need to add the following to httpd.conf: *** LoadModule perl_module modules/mod_perl.so But the actual make doesn't go so well: jweisen@kaitain$ sudo make ... ranlib: mod_perl.so: Inappropriate file type or format *** Error code 1 Stop in /usr/local/src/mod_perl-1.99_08/src/modules/perl (line 149 of Makefile.modperl). *** Error code 1 Stop in /usr/local/src/mod_perl-1.99_08 (line 459 of Makefile). I dug back a couple months in the mailing lists and I'm not seeing anything applicable. Any help would be appreciated. Actually there were several reports of a similar failure for mod_perl 2.0 and even more for mod_perl 1.0. It looks like you've snipped too much and you don't show what are the unresolved symbols, which seems to be the cause of the error: ranlib: mod_perl.so: Inappropriate file type or format __ 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: Apache::Request incompatible with CGI ?
I downloaded Apache::Request from CPAN and I have version 0.31. My C compiler is gcc 2.96 aiya. libapreq 0.31 is the one that likes to append whatever it is that one just uploaded to it to its heap until it starves your machine of memory, if i recall correctly. it was fixed in 0.31_03 i believe but it looks like 1.1 was released last week. .dorian
handling of the trailing slash
Apache/1.3.26 + mod_perl/1.27 I've noticed that Apache alone appears to differ from one of my modules running under mod_perl in its handling of trailing slashes. I'm wondering if this is expected behavior and, if so, why? (Maybe this is obvious...) For example: the file news.html exists in /var/www/html/. I issue four requests to Apache alone, one for /news.html, one for /news, one for /news/ and one for /news.html/, and then the same four requests again, this time under mod_perl. The second time, under mod_perl, I use a basic little module that simply records the value of $r-filename to the error log and then sends the contents of the file to the browser (after opening it with Apache::File, similar to the Ch. 4 Eagle book instructions). (No directory called /var/www/html//news exists, nor are there any symlinks involved.) Here's a table of the results: Apache --- /news.html /news /news/ /news.html/ 200 200 404 404 200 means success, data displayed was from news.html. The error log showed that /news.html/ was not found in the case of the 404s. Apache+mod_perl --- /news.html /news /news/ /news.html/ 200 200 200 200 200 means success, data displayed was from news.html, error_log recorded /var/www/html/news.html in all cases as the value of $r-filename (thanks to my little Perl module logging this value for me). In the cases of /news/ and /news.html/, my relative image links broke (for hopefully obvious reasons). Is this expected behavior? Why? I would expect Apache and Apache+mod_perl to behave similarly. Am I missing something obvious? (Probably...) Thanks, Kris P.S. Just for kicks, I tried a similar set of four URLs at stonehenge.com, and they all displayed the same data (of course, I don't run that server, I just happen to read Randal Schwartz's columns...): http://www.stonehenge.com/perltraining/instructors.html http://www.stonehenge.com/perltraining/instructors http://www.stonehenge.com/perltraining/instructor/ http://www.stonehenge.com/perltraining/instructors.html/ -- kristopher nelson
Re: handling of the trailing slash
kris nelson wrote: Apache/1.3.26 + mod_perl/1.27 I've noticed that Apache alone appears to differ from one of my modules running under mod_perl in its handling of trailing slashes. I'm wondering if this is expected behavior and, if so, why? (Maybe this is obvious...) For example: the file news.html exists in /var/www/html/. I issue four requests to Apache alone, one for /news.html, one for /news, one for /news/ and one for /news.html/, and then the same four requests again, this time under mod_perl. The second time, under mod_perl, I use a basic little module that simply records the value of $r-filename to the error log and then sends the contents of the file to the browser (after opening it with Apache::File, similar to the Ch. 4 Eagle book instructions). (No directory called /var/www/html//news exists, nor are there any symlinks involved.) Here's a table of the results: Apache --- /news.html /news /news/ /news.html/ 200 200 404 404 200 means success, data displayed was from news.html. The error log showed that /news.html/ was not found in the case of the 404s. Apache+mod_perl --- /news.html /news /news/ /news.html/ 200 200 200 200 200 means success, data displayed was from news.html, error_log recorded /var/www/html/news.html in all cases as the value of $r-filename (thanks to my little Perl module logging this value for me). In the cases of /news/ and /news.html/, my relative image links broke (for hopefully obvious reasons). Is this expected behavior? Why? I would expect Apache and Apache+mod_perl to behave similarly. Am I missing something obvious? (Probably...) It's hard to guess what your relevant configuration is. Care to send in the mod_perl and Apache sections? Including things like Multiviews Options, DirectoryIndex, etc. Basically it all comes to the following logic: mod_perl sections inherit all the default Apache settings unless you've overriden them. And this is true for any other module, be it mod_perl or not. __ 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: handling of the trailing slash
kris == kris nelson [EMAIL PROTECTED] writes: kris I've noticed that Apache alone appears to differ from one of my kris modules running under mod_perl in its handling of trailing kris slashes. I'm wondering if this is expected behavior and, if so, kris why? (Maybe this is obvious...) Yes, expected. mod_core gets upset if there are characters in PATH_INFO trailing the filename. But mod_cgi doesn't care, nor does mod_perl's Apache::Registry. If you write your own handler, you can return errors for data in PATH_INFO. It's up to you. You didn't say what handler you were using (hint: mod_perl is never specific enough :). -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Different modules, same names, random results
Hello everyone, I am currently running a web server using Perl CGI for all my web sites and have been attracted to mod_perl for the performance advantages - particularly not having to start a new perl interpreter for each request. I have tried using Apache::Register and Apache::PerlRun but am having problems due to the fact that each web site refers to their own copy of my module called Site.pm (to contain functions, global variables etc). The problem is that the my scripts get confused and use variables from the other site's modules randomly. The following example is using Apache::PerlRun (as it's supposed to be more forgiving that Apache::Register). I am using Apache 1.3.26 and mod_perl 1.26 on Debian Woody. .htaccess - PerlModule Apache::PerlRun files *.pl SetHandler perl-script PerlHandler Apache::PerlRun Options +ExecCGI /files site1.pl #!/usr/bin/perl use strict; use CGI; use lib lib1; use Site; my $q = new CGI; print $q-header(); print EOF; Site 1br VAR: $VARbr EOF lib1/Site.pm #!/usr/bin/perl -w package Site; require Exporter; use strict; our $VAR = Site one; our @ISA = qw(Exporter); our @EXPORT = qw($VAR); 1; site2.pl #!/usr/bin/perl use strict; use CGI; use lib lib2; use Site; my $q = new CGI; print $q-header(); print EOF; Site 2br VAR: $VARbr EOF lib2/Site.pm #!/usr/bin/perl -w package Site; require Exporter; use strict; our $VAR = Site two; our @ISA = qw(Exporter); our @EXPORT = qw($VAR); 1; I then call site1.pl and site2.pl multiple times and get output like this: Site 1 VAR: Site two Site 1 VAR: Site one Site 1 VAR: Site two Site 2 VAR: Site two Site 2 VAR: Site two Site 2 VAR: Site one I can fix this problem by adding the line PerlSetVar PerlRunOnce On to my .htaccess file, but my performance tests show that this is actually slower than regular CGI!! Is there anything I can do to make this work properly without renaming all my Site.pm modules (and all scripts that call them) to have unique names? Thanks, Pinunki __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Different modules, same names, random results
this is probably evil, and apologies to those who have seen suspiciously
familiar code before, but is this possible?
package MyPrefix::Apache::Registry;
use strict;
BEGIN {
use Apache::Registry();
}
sub handler {
delete $INC{'Site.pm'};
# mess with @INC
require Site;
return (Apache::Registry::handler(@_));
}
END { }
1;
that would allow you to keep perl resident, keep the cgi-scrip resident
and simply reload a small? configuation perl module each time.
(i think?) :)
Uru
-Dave
Pinunki wrote:
Hello everyone,
I am currently running a web server using Perl CGI for
all my web sites and have been attracted to mod_perl
for the performance advantages - particularly not
having to start a new perl interpreter for each
request. I have tried using Apache::Register and
Apache::PerlRun but am having problems due to the fact
that each web site refers to their own copy of my
module called Site.pm (to contain functions, global
variables etc). The problem is that the my scripts get
confused and use variables from the other site's
modules randomly.
The following example is using Apache::PerlRun (as
it's supposed to be more forgiving that
Apache::Register). I am using Apache 1.3.26 and
mod_perl 1.26 on Debian Woody.
.htaccess
-
PerlModule Apache::PerlRun
files *.pl
SetHandler perl-script
PerlHandler Apache::PerlRun
Options +ExecCGI
/files
site1.pl
#!/usr/bin/perl
use strict;
use CGI;
use lib lib1;
use Site;
my $q = new CGI;
print $q-header();
print EOF;
Site 1br
VAR: $VARbr
EOF
lib1/Site.pm
#!/usr/bin/perl -w
package Site;
require Exporter;
use strict;
our $VAR = Site one;
our @ISA = qw(Exporter);
our @EXPORT = qw($VAR);
1;
site2.pl
#!/usr/bin/perl
use strict;
use CGI;
use lib lib2;
use Site;
my $q = new CGI;
print $q-header();
print EOF;
Site 2br
VAR: $VARbr
EOF
lib2/Site.pm
#!/usr/bin/perl -w
package Site;
require Exporter;
use strict;
our $VAR = Site two;
our @ISA = qw(Exporter);
our @EXPORT = qw($VAR);
1;
I then call site1.pl and site2.pl multiple times and
get output like this:
Site 1
VAR: Site two
Site 1
VAR: Site one
Site 1
VAR: Site two
Site 2
VAR: Site two
Site 2
VAR: Site two
Site 2
VAR: Site one
I can fix this problem by adding the line PerlSetVar
PerlRunOnce On to my .htaccess file, but my
performance tests show that this is actually slower
than regular CGI!!
Is there anything I can do to make this work properly
without renaming all my Site.pm modules (and all
scripts that call them) to have unique names?
Thanks,
Pinunki
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Re: Different modules, same names, random results
David Dick wrote:
this is probably evil, and apologies to those who have seen suspiciously
familiar code before, but is this possible?
package MyPrefix::Apache::Registry;
use strict;
BEGIN {
use Apache::Registry();
}
sub handler {
delete $INC{'Site.pm'};
# mess with @INC
require Site;
return (Apache::Registry::handler(@_));
}
a simpler way is to do:
do Site.pm;
though you forgot to call the import, when removing use, so you do:
do Site.pm;
Site-import(whatever);
and if you use:
use warnings;
you probably want to add:
no warnings 'redefine';
END { }
1;
that would allow you to keep perl resident, keep the cgi-scrip resident
and simply reload a small? configuation perl module each time.
(i think?) :)
indeed. This is discussed here:
http://perl.apache.org/docs/1.0/guide/porting.html#Name_collisions_with_Modules_and_libs
__
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: Different modules, same names, random results
Pinunki wrote:
[...]
I have tried using Apache::Register and
Apache::PerlRun but am having problems due to the fact
that each web site refers to their own copy of my
module called Site.pm (to contain functions, global
variables etc). The problem is that the my scripts get
confused and use variables from the other site's
modules randomly.
[...]
If your module which has an indentical name but different contents and it
never calls functions and accesses variables by prefixing the module name
(e.g. Site::foo and $Site::bar), i.e. everything is exported, you could hack
Apache::Registry to compile the different files into different package names
and do the importing for you. Here is the proof of concept (untested!) code.
All it does, is reading the file (Site.pm in your case), prepending the string
'package foo_bar_tar_lib1_Site_pm;'
to the contents of the file, compiling the module via eval and then calling
import() to import all the stuff as it did before. Notice that you do have to
change your scripts to call the trickery my_use().
(Alternatively you could try to play with aliasing of the namespaces, instead
of mangling the file contents, but this could introduce problems...)
my_script.pl:
-
my @imports();
Apache::Registry::my_use('Site.pm', @imports);
Site.pm
---
# no package declaration!
# the rest is as usual Exporter, vars, subs
# blah, blah
1;
Registry.pm
---
package Apache::Registry;
# the normal Registry stuff ...
# then the extra stuff:
use File::Spec::Functions;
sub my_use {
my($module, @import) = @_;
my $file = catfile Apache-request-filename, $module;
my $namespace = make_namespace($file);
compile($namespace, $file) or die failed to compile: $@;
$namespace-import(@import);
}
sub make_namespace {
my ($path) = @_;
$path =~ s/([^A-Za-z0-9_])/sprintf(_%2x, unpack(C, $1))/eg;
# make sure that the sub-package doesn't start with a digit
$path =~ s/^(\d)/_$1/;
return $path;
}
sub compile {
my ($namespace, $file) = @_;
open my $fh, $file;
local $/;
my $data = $fh;
close $fh;
{ eval package $namespace;\n $data; }
return $@ ? 0 : 1;
}
1;
__
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: Possible bug with a 206 Partial Response
David Dick wrote:
alrightly, back again. The problem is that Apache::Registry will return
a 206, which will trigger the error message. In case there is anyone
out there as daft as me :), the crude delegation-type module below can
solve this problem. Maniacs who see a need to return 204's, etc can
probably extend this to a more general solution. :)
package MyPrefix::Apache::Registry;
use strict;
BEGIN {
use Apache::Registry();
use Apache::Constants qw(:common);
use constant PARTIAL_CONTENT = 206;
}
sub handler {
my ($return) = Apache::Registry::handler(@_);
if ($return == PARTIAL_CONTENT) {
return OK;
} else {
return ($return);
}
}
END { }
1;
When I've tried to run your test script under ModPerl::Registry
(mp2.0) I was surprised to learn that it worked just fine. So far I
was fixing the porting bugs ;) I've added your test script to the
ModPerl::Registry test suite.
We better fix it in the 1.0 core. But before that we need to be clear of how
the return codes should be handled, because the currect three implementations
all diverge when it comes to handling the return codes/execution status.
In order to simplify the logic, assuming that the script was
successfully executed and inlining some code, the 3 different registry
implementations resemble the following:
Apache::Registry does:
my $old_status = $r-status;
eval { {$cv}($r, @_) };
return $r-status($old_status);
Apache::PerlRun/RegistryNG do:
my $old_status = $r-status;
eval { {$cv}($r, @_) };
$r-status($old_status);
return OK;
ModPerl::RegistryCooker does:
# handlers shouldn't set $r-status but return it
my $old_status = $self-[REQ]-status;
eval { {$cv}($r, @_) };
my $new_status = $self-[REQ]-status;
# only if the script has changed the status, reset to the old
# status and return the new status
return $old_status != $new_status
? $self-[REQ]-status($old_status)
: OK;
If I'm correct both Apache::PerlRun and Apache::Registry will have
problems in certain situations if we agree that ModPerl::Registry has
the correct logic for handling the execution status. If you can tell
otherwise please give me a test script that doesn't work under
ModPerl::Registry.
But in your particular example, Dick, if you configure the
script to run under Apache::RegistryNG, does it work? If not, that's where the
difference between 1.0 and 2.0 lays: ModPerl::Registry doesn't reset status if
it wasn't changed by the script.
__
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: Possible bug with a 206 Partial Response
If I'm correct both Apache::PerlRun and Apache::Registry will have problems in certain situations if we agree that ModPerl::Registry has the correct logic for handling the execution status. If you can tell otherwise please give me a test script that doesn't work under ModPerl::Registry. But in your particular example, Dick, if you configure the I'm presuming that you simply mixed up which is my first name and surname? :) Usually dave is fine. :) script to run under Apache::RegistryNG, does it work? No. If not, that's where the difference between 1.0 and 2.0 lays: ModPerl::Registry doesn't reset status if it wasn't changed by the script. well the ModPerl::Registry behaviour certainly suits my program. :) Uru -dave
