Re: path recognition question

[Michael A. Capone]

(Sorry for the late reply, been out of town)

Recognizing that I've never gone as indepth with mod_perl as other 
users, but it seems to me that accessing "id" here would just be a 
matter of grabbing the PATH_INFO environment variable, wouldn't it?


if the url is www.example.com/app/user/12345, then the program is 
/app/user, and $ENV{'PATH_INFO'} would contain /12345.  Chop off the 
leading forward slash and you've got your ID.


Note that you'd have to have PerlSetupEnv on (the default, although I 
think many may turn it off).


Or am I completely missing something?

Michael

On 4/21/22 6:40 AM, John Dunlap wrote:

I ended up writing something custom to do that.

On Wed, Apr 20, 2022 at 11:22 PM Henrik S > wrote:


given the sample url:

/api/user/id

the part of "/api/user" is fixed.  and there is a handler setup
for this
path.

how to get the id part in mod_perl?

in other framework I could get it with the similar format:

/api/user/:id

puts "hallo #{id}"


Thank you.



--
John Dunlap
/CTO | Lariat/
/
/
/*Direct:*/
/j...@lariat.co /
/
*Customer Service:*/
877.268.6667
supp...@lariat.co 

Re: HTTP and MPM support

[Michael A. Capone]

On 1/25/19 10:54 AM, Randolf Richardson wrote:

On 25.01.2019 18:35, John Dunlap wrote:

I'm in the process of optimizing our web application for performance and one 
thing that I
was really excited to try was mod_http2 because it allows the browser to send 
multiple
requests through the same TCP connection with compressed headers.



  Are there any plans to support other MPM's? If not, the
benefits of HTTP2 appear to be permanently out of reach for our mod_perl 
applications and
that, honestly, might force us into seriously reevaluating our technology 
stack. :(


Am I allowed to jump into the same thread, and ask about what the general 
status of
mod_perl is, nowadays (if someone knows) ?



(Mind you, for us MPM prefork and HTTP 1.1 are still perfectly ok, but the 
question is
more about the longer-term future).

I'm also curious about this as I anticipate HTTP/2 support becoming
a valuable and important feature in the future (the recent updates to
mod_perl2 have been good for us).

Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/


I have to add my voice to the growing chorus here.  As it stands, we are 
forced to choose between mod_perl and HTTP/2.  At the moment, our shop 
has chosen to keep mod_perl, but I share the above concerns, and I'd 
rather see mod_perl be ready if there is ever a major cultural shift / 
push to HTTP/2 in the broader market.

Re: Future MPM Support?

[Michael A. Capone]

Yes, http/2 is our primary concern right now.  At the moment, we've made 
the business decision to stay on mod_perl rather than migrate to another 
platform and gain http/2 benefits, but for how long can we maintain that 
decision?  I'm honestly not sure.


Now, we significantly under-utilize mod_perl, mostly doing CGI registry 
/ code caching.  Hey, if it was good 15 years ago, it's good today! :)  
But that does mean that there are potentially other options for us to 
explore, as we're not married to all the bells and whistles that 
mod_perl provides.


On 8/4/2018 5:47 AM, Paul Silevitch wrote:

Also issues with http/2 since it is not supported by prefork mpm anymore.

On Wed, Aug 1, 2018 at 12:44 PM, John Dunlap > wrote:


The biggest deficiency of mod_perl, at the moment, is that it
cannot provide web sockets. In today's world, that's a huge problem.

On Wed, Aug 1, 2018 at 11:30 AM, Robert Smith
mailto:spamf...@wansecurity.com>> wrote:

Who in the world would want to abandon mod_perl?

What is this world coming to?

-Robert

> On Jul 30, 2018, at 5:44 PM, André Warnier (tomcat)
mailto:a...@ice-sa.com>> wrote:
>
> On 30.07.2018 03:51, Paul B. Henson wrote:
>> On Sun, Jul 29, 2018 at 04:18:54PM -0400, Paul Silevitch wrote:
>>> Like Dr. James Smith, I'm hooking into multiple handlers
and using filters.
>>
>> Yep, me too; Plack is really not a feature equivilent
replacement for
>> mod_perl :(.
>>
> +1.
> Plack and other frameworks (TT2, Moose, Catalyst, etc.)
cover the web application side, at different levels and in
different ways.
> But there is (to my knowledge) no equivalent for mod_perl's
ability to interact deeply with the Apache internal Request
processing logic.
> In that respect, comparing mod_perl to Plack etc is like
comparing apples to pears : not very relevant.
> Considering that, for better or worse, Perl as a programming
language does not seem to be really attractive to the current
generation of software developers anymore, I would not really
mind if some tool equivalent to mod_perl was developed using
whichever other scripting language is currently more in
fashion (javascript ? python ? ..), but it really seems a pity
to "slowly abandon" mod_perl without providing some tool of
equivalent power in terms of deep interaction with Apache httpd.
>
>
>




-- 
John Dunlap

/CTO | Lariat/
/
/
/*Direct:*/
/j...@lariat.co /
/
*Customer Service:*/
877.268.6667
supp...@lariat.co 

Re: Upgrade to Debian stretch (stable) breaks my unique token

[Michael A. Capone]

On 03/01/2018 02:30 PM, Vincent Veyron wrote:


Now, if you happen to know why this _had_ to surface during a demo [:-(


The University of Nottingham, School of Mathematical Sciences, published 
a highly technical paper explaining this phenomenon.  Hope this helps:  :-)


https://www.maths.nottingham.ac.uk/personal/ibf/some.html

Re: CGI module deprecation

[Michael A. Capone]

"and uses the CGI module only for parsing the incoming request."

I was going to follow up on this thread and ask for suggestions on what 
I could/should use for incoming request parsing.  I have never gone 
further in mod_perl beyond Apache::Registry and just running traditional 
CGI programs, and I only use CGI.pm to get the request parameters (but I 
use it a LOT).  Is there another modeule that I can drop in to get that 
functionality?  Or should I happily keep using CGI.pm (which I have no 
problem installing from CPAN as long as it's available).


On 11/29/2017 01:13 PM, Randal L. Schwartz wrote:

My CGI::Prototype is still in use by one of my primary clients, and uses
the CGI module only for parsing the incoming request.  The rest is a
nice prototype-inheritance structure of Template Toolkit objects.

print "Just another Perl hacker,";

Re: "SetEnv/SetEnvIf" and mod_perl

[Michael A. Capone]

In my code, I do:


SetEnvIf Request_URI \.gif$ gif-image
SetHandler modperl
PerlResponseHandler MyNiftyModule
PerlOptions +SetupEnv


And then, yes, I have access to $ENV{'gif-image'}, with a value of "1".

Alternatively, i can
   SetEnvIf Request_URI \.gif$ gif-image=YES

... and $ENV{'gif-image'} will have a value of 'YES'.

Note that you have to do
PerlOptions +SetupEnv
in order for this to pass through (as far as i know; unsetting it made 
my custom $ENV's go away).


In a perfect world, we would have "PerlSetEnvIf". :)

On 10/02/2015 02:39 AM, André Warnier wrote:

Hi again.

Assuming this kind of configuration :


SetEnvIf Request_URI \.gif$ gif-image
SetHandler modperl
PerlResponseHandler MyNiftyModule
..


is there any way, in MyNiftyModule, to "get at" this "gif-image" 
variable ?


Such as, would I find it as $ENV{'gif-image'} ?
What kind of thing are these "Apache environment variables" anyway ?
I have been using them extensively within Apache itself, but I still 
can't quite figure out on what plane they live.  Clearly, they are not 
"environment variables" in the same sense as "cgi-bin environment 
variables", and not the same thing either as what a "PerlsetVar" does, 
so what are they ?


(And I realise that this is more of an Apache httpd question, but I 
figure that if someone should be aware of the httpd internals, there 
is a good chance of finding such a person here).

Re: Odd behavior with IO::Socket::SSL and mod_perl 2.0.8

[Michael A. Capone]

So, it turns out that IO::Socket::SSL v2.005 -- in particular, the 
PublicSuffix.pm -- wasn't thread-safe, which was causing it to fail in 
the mod_perl environment.  They released v2.006 over the weekend, which 
addresses this issue (as well as others).  I did verify today that the 
new version works well.


Thanks for listening!
Michael

Michael A. Capone wrote:

Hello,

I'll try not to make this too convoluted... :)

The latest version of IO::Socket::SSL on CPAN is v2.005 and includes a 
module IO::Socket::SSL::PublicSuffix.  When attempting to use this 
version of IO::Socket::SSL in modperl, we got a strange 500 Internal 
Server error.  Some debugging led to PublicSuffix.pm.  Lines 291-301 
of that file basically read in data from the __DATA__ section at the 
end of the file, until they hit a particular marker.  The way the code 
is written to do it works fine on the command line, but fails in 
mod_perl.


I distilled the whole thing down to a trivial registry cgi:

##
print "Content-type: text/plain\n\n";

my $test = _default_data();

print "length of test is " . length($test) . "\n";

# this block here is directly copied from lines 291-301 of 
PublicSuffix.pm

{
   my $data;
   sub _default_data {
   if ( ! defined $data ) {
   $data = do { local $/;  };
   $data =~s{^// ===END ICANN DOMAINS.*}{}ms
   or die "cannot find END ICANN DOMAINS";
   }
   return $data;
   }
}

__DATA__

// ===BEGIN ICANN DOMAINS===

edu.ac

// zone : 2013-11-14 Outer Falls, LLC
zone

// ===END ICANN DOMAINS===
// ===BEGIN PRIVATE DOMAINS===

za.org

// ===END PRIVATE DOMAINS===
##

If you run that cgi on the command line, it correctly prints "length 
of test is 83"; in a mod_perl environment, it yields:


[Fri Nov 21 11:23:28 2014] [error] cannot find END ICANN DOMAINS at 
/usr/local/mysite/www/cgi-bin/test.cgi line 12.\n


My gut-level feeling is that the writers of that code are committing 
some mod-perl sin somewhere.  The line:

  $data = do { local $/;  };
... yields an empty $data in mod_perl.

The problem is, IO::Socket::SSL is used by LWP::UserAgent, which is 
probably used by a ton of mod-perl scripts out there.

My questions, then, are:

1) can you fine folk reproduce this?
2) what would be the best way to address it?

Thanks!
Michael

Odd behavior with IO::Socket::SSL and mod_perl 2.0.8

[Michael A. Capone]

Hello,

I'll try not to make this too convoluted... :)

The latest version of IO::Socket::SSL on CPAN is v2.005 and includes a 
module IO::Socket::SSL::PublicSuffix.  When attempting to use this 
version of IO::Socket::SSL in modperl, we got a strange 500 Internal 
Server error.  Some debugging led to PublicSuffix.pm.  Lines 291-301 of 
that file basically read in data from the __DATA__ section at the end of 
the file, until they hit a particular marker.  The way the code is 
written to do it works fine on the command line, but fails in mod_perl.


I distilled the whole thing down to a trivial registry cgi:

##
print "Content-type: text/plain\n\n";

my $test = _default_data();

print "length of test is " . length($test) . "\n";

# this block here is directly copied from lines 291-301 of PublicSuffix.pm
{
   my $data;
   sub _default_data {
   if ( ! defined $data ) {
   $data = do { local $/;  };
   $data =~s{^// ===END ICANN DOMAINS.*}{}ms
   or die "cannot find END ICANN DOMAINS";
   }
   return $data;
   }
}

__DATA__

// ===BEGIN ICANN DOMAINS===

edu.ac

// zone : 2013-11-14 Outer Falls, LLC
zone

// ===END ICANN DOMAINS===
// ===BEGIN PRIVATE DOMAINS===

za.org

// ===END PRIVATE DOMAINS===
##

If you run that cgi on the command line, it correctly prints "length of 
test is 83"; in a mod_perl environment, it yields:


[Fri Nov 21 11:23:28 2014] [error] cannot find END ICANN DOMAINS at 
/usr/local/mysite/www/cgi-bin/test.cgi line 12.\n


My gut-level feeling is that the writers of that code are committing 
some mod-perl sin somewhere.  The line:

  $data = do { local $/;  };
... yields an empty $data in mod_perl.

The problem is, IO::Socket::SSL is used by LWP::UserAgent, which is 
probably used by a ton of mod-perl scripts out there. 


My questions, then, are:

1) can you fine folk reproduce this?
2) what would be the best way to address it?

Thanks!
Michael

Re: Unsuccessful stat on filename containing newline in RegistryCooker.pm

[Michael A. Capone]

Torsten Förtsch wrote:

On 02/28/2013 11:59 AM, Torsten Förtsch wrote:
  

I agree with you that the behavior is unexpected. Also, the XXX comment
in line 783 points out that my_finfo() is a temporary solution. So,
perhaps it would be best to use APR::Finfo here. If family allows it
I'll fix it over the weekend.



See revision 1451907.

Torsten
Torsten, I thank you kindly!  You've made the world brighter and my 
error logs cleaner! :)  My regards to your family for their forbearance.

Re: Re: Unsuccessful stat on filename containing newline in RegistryCooker.pm

[Michael A. Capone]

(Sorry so slow in responding, been out of the office)

Randolf Richardson wrote:

Hi Folks,

I'm reasonably certain that this is just a misconfigured mod_perl server 
on my part, but I can't seem to find a solution for it.


We are currently running ModPerl::Registry to serve legacy CGI code.  
Now, consider the following URL, with an embedded newline:


http://www.mysite.com/cgi-bin/search.cgi%0d%0a

Since we obviously don't have a CGI file named with a trailing newline 
character, I would expect apache to return a 404 Not Found.  However, 
apache happily hands the URL off to mod_perl, which attempts to stat 
search.cgi(newline), and fails with:



	ModPerl is correct if the filename supplied doesn't exist (which you 
seem to be implying that it doesn't), and what's really nice is that 
it's informing you of the likely problem with the filename.


	The URL that people should be using should just end with 
"search.cgi" and if they're typing this in and adding "%0d%0a" to the 
end of it then they deserve to receive a 404 Not Found error.
I agree completely!  Unfortunately, that's not what's happening.  We're 
not getting a 404, we're getting a 500 Internal Server Error.  I guess 
that is because perl is throwing an untrapped exception when it sees the 
filename-with-newline.  But yes, my issue is that such a request 
generates a 500. I feel that mod_perl should be returning 404 in this 
case, since the file is indeed not found.


Generally, these kinds of requests are attempts at HTTP header-injection 
or similar attacks.  So I'm under no obligation to be helpful to them :)


Thoughts?

Thanks,
MAC





I hope this helps.

[End of reply.]

  
[Wed Feb 13 16:27:33 2013] [error] [client 192.168.254.21] Unsuccessful 
stat on filename containing newline at 
/usr/local/lib64/perl5/ModPerl/RegistryCooker.pm line 787.\n


... which in turn results in a 500 Server Error.

Trying a similar URL with a php file on the same server correctly 
returns a 404.  Also, requesting a file like 
/cgi-bin/this_file_does_not_exist.cgi correctly returns a 404.  However, 
/cgi-bin/this_file_does_not_exist.cgi%0d%0a returns 500.


What can / should I do to get the "correct" behaviour out of mod_perl?  
I could probably do something with a mod_rewrite RewriteRule to strip 
newlines, but I feel like I shouldn't have to run every request through 
a RewriteRule.  I could also accept if mod_perl treated this as a 
warning, but that's not the case here.


Here is line 787 of RegistryCooker.pm, btw:

783: # XXX: should go away when finfo() is ported to 2.0 (don't want to
784: # depend on compat.pm)
785: sub Apache2::RequestRec::my_finfo {
786: my $r = shift;
787: stat $r->filename;
788: \*_;
789: }

Thoughts?

Thanks!
Michael




  

Unsuccessful stat on filename containing newline in RegistryCooker.pm

[Michael A. Capone]

Hi Folks,

I'm reasonably certain that this is just a misconfigured mod_perl server 
on my part, but I can't seem to find a solution for it.


We are currently running ModPerl::Registry to serve legacy CGI code.  
Now, consider the following URL, with an embedded newline:


http://www.mysite.com/cgi-bin/search.cgi%0d%0a

Since we obviously don't have a CGI file named with a trailing newline 
character, I would expect apache to return a 404 Not Found.  However, 
apache happily hands the URL off to mod_perl, which attempts to stat 
search.cgi(newline), and fails with:


[Wed Feb 13 16:27:33 2013] [error] [client 192.168.254.21] Unsuccessful 
stat on filename containing newline at 
/usr/local/lib64/perl5/ModPerl/RegistryCooker.pm line 787.\n


... which in turn results in a 500 Server Error.

Trying a similar URL with a php file on the same server correctly 
returns a 404.  Also, requesting a file like 
/cgi-bin/this_file_does_not_exist.cgi correctly returns a 404.  However, 
/cgi-bin/this_file_does_not_exist.cgi%0d%0a returns 500.


What can / should I do to get the "correct" behaviour out of mod_perl?  
I could probably do something with a mod_rewrite RewriteRule to strip 
newlines, but I feel like I shouldn't have to run every request through 
a RewriteRule.  I could also accept if mod_perl treated this as a 
warning, but that's not the case here.


Here is line 787 of RegistryCooker.pm, btw:

783: # XXX: should go away when finfo() is ported to 2.0 (don't want to
784: # depend on compat.pm)
785: sub Apache2::RequestRec::my_finfo {
786: my $r = shift;
787: stat $r->filename;
788: \*_;
789: }

Thoughts?

Thanks!
Michael

Re: protecting internal redirects

[Michael A. Capone]

Both very good points!  I stand corrected.

Michael Peters wrote:

On 03/18/2010 06:05 PM, Michael A. Capone wrote:

This would be the most secure way.


Saying it's the *most* secure way is a little stretch. It's *another* 
secure way. Also, keeping a large Perl/CGI process alive just to serve 
a static file is a waste. In fact, if you can think of a mod_rewrite 
rule to automatically look for the cached file first and send that 
before even getting to the CGI script would be your best bet for 
performance.

Re: protecting internal redirects

[Michael A. Capone]

Rather than doing the URL redirect, why not just keep the cached results 
in a private directory, and let the CGI open them and serve them up 
directly?  This would be the most secure way.


So, you could do something like this:


print "Content-type: text/html\n\n"; # or whatever the appropriate 
content-type is


$cached_file_name = FigureOutRequest();  # find out if the result is 
already cached in a file


if ($cached_file_name != "")
{
  open CACHEFILE, "/path/to/$cached_file_name";
  print STDOUT ;  # send output to browser
  close CACHEFILE;
}
else
{
   $generated_result = DoAllTheWork();
   $new_cache_file = "appropriate_name.txt";# save the generated 
result into the cache...

   open CACHEOUT, "> /path/to/$new_cache_file";
   print CACHEOUT $generated_result;
   close CACHEOUT;

   print STDOUT $generated_result;  # ... and then send it 
back to the browser.

}

Would that get the job done?

E R wrote:

Hi all,

This is not exactly a mod_perl question - in fact I hope there is a
solution which does not use mod_perl.

I have a CGI script which generates a lot of output. Because it takes
a lot of time to the output, the results are cached in case the same
request is made again.

To serve the file the CGI script issues an internal redirect to a url
which points to the cached results.

My question is: can the url which points to the cached results be
protected so that it cannot be directly accessed by external clients?

For example:

1. user makes a request
2. CGI script handles request. It computes a file name for the
results, generates the results and places the result in that file.
3. The CGI script then emits an internal redirect to a url which will
map to the file name determined in step 2.
4. Apache will process the internal redirect and serve the contents of
the file to the client.

I want to prevent the clients from accessing the file directly by
figuring out what the url is in step 3.
I know that clients will not see the internal redirect, but I also
want to prevent them from guessing it.

Is there an Apache configuration I can use to accomplish this, or do I
need to use mod_perl?

Thanks,
ER

  

Re: How to get a file listing

[Michael A. Capone]

Depending on your server setup, you may or may not be able to read 
\mydir2\.  Whether on windows or a unix variant, apache is configured to 
run as "some user" (often, "nobody" on unix); and that user needs to be 
given at least read access to the \mydir2\ directory in order for this 
to work.


Alan young's snippet he gave you: 


  opendir my $DH, '\mydir2\' or die "Unable to open mydir2: $!";

should quickly tell you if you don't have read permission on \mydir2.




ceauke wrote:

Wow, thanks. It's working. I have a problem with the dir structure:
Perls seems to search for mydir in \cgi-bin\ and not where I defined mydir
in the apache conf file.

So my structure is like this:
\cgi-bin\myprog.cgi   < my program
\cgi-bin\mydir1\   <- this one can be seen by my program
\mydir2\<- how do I show this content?
  

Re: How to get a file listing

[Michael A. Capone]

#!/usr/local/bin/perl

chdir("/path/to/my/directory");

while($filename=<*.gif>)
{
   print "$filename\n";
}

# Enjoy!


ceauke wrote:

Hi guys

I wanted to do a simple script to show all pictures in a specific folder.
But I don't see any functions to read all files in a folder.

The logic needs to go something like this:
- Open directory to read file list
- If file like *.gif then print  filename 


Any tips?
  

Filter out error log by IP address?

[Michael A. Capone]

Hello,

I'm not sure this is a mod_perl question per se, but I'm hoping there's 
a mod_perl solution to our problem.


We currently use a 3rd party security company to do a nessus-type 
security audit on our site for PCI compliance.  Their scans naturally 
generate a lot of noise in the error log, to the point that legitimate 
site errors are lost in the forest.  What I'm hoping to find / create is 
some kind of mechanism that can pre-empt writing to the error log and 
either 1) ideally, don't log if the client IP is xxx.xxx.xxx.xxx, or 2) 
always log the client IP address with each error, which will enable us 
to filter those out manually after the fact.  Either solution is acceptable.


Apache provides a trivial solution for the access_log, in the form of:

   SetEnvIf Remote_Addr xxx.xxx.xxx.* nolog

... however, that solution does not extend to the error log.  I'm hoping 
there's a mod_perl "hook" that can allow me to change apache's error 
logging behaviour to what I need it to be.


Can someone point me in the right direction?

Re: ErrorDocument from a registry script

[Michael A. Capone]

In the spirit of checking off the obvious things... are you sure that 
the ErrorDocument directive is working for other pages?  in other words, 
can you open a browser and goto 
http://mydomain.com/this_file_does_not_exist.htm and see your ErrorDocument?


Michael Peters wrote:
I'm pretty sure this should just work and I'm doing something stupid, 
so any helpful insults that point me in the right direction would be 
appreciated :)


I have a registry script that could return a NOT FOUND (404) error. 
I'm handling that like so:


  Apache->request->status(NOT_FOUND);

The browser does get the 404 HTTP status header, but it does not 
trigger the ErrorDocument 404 that is set up, instead just showing the 
browser's built-in 404 message. PerlSendHeaders is Off and I'm not 
printing any output.

Re: mod_perl handler and PHP

[Michael A. Capone]

Perhaps something like this might work?

in index.php:

  $phpcode = 
file_get_contents("http://127.0.0.1/path/to/perl/module/that/outputs/php/code.pl";);

  eval($phpcode);

Obviously, you'd have to take care with the php syntax that was output 
from code.pl, but that might give you the functionality you're looking 
for.  We've done similar things where perl was better suited to a 
particular task on a page that otherwise wanted PHP.


daniel.angil...@imperia.net wrote:


Hello list,

is it possible to parse the output of mod_perl handler through PHP?

I tried like this:

### httpd.conf ###
PHPIniDir "C:/PHP/"
LoadModule php5_module "C:/PHP/php5apache2_2.dll"

### vhost.conf ###

  SetHandler modperl
  PerlHandler My::Handler
  SetOutputFilter PHP



When I trie to call up /ls/app/demo/index.php the Apache serves me the 
file for downloading.


Apache 2.2.6 (Win32)
PHP 5.2.9
mod_perl 2.0.3
Active Perl v. 5.8.8


Has anyone already set up this szenario?


Regards
Daniel 

Re: How to require() a file?

[Michael A. Capone]

Stanisław T. Findeisen wrote:
I am trying to require() a file using its absolute name. In command 
line mode everything works fine, but not in Apache: [Fri Feb 27 
17:45:07 2009] [error] Can't locate 
/home/stf/public_html/test/arcv/public_html/../common.pl in @INC (@INC 
contains: /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi


How can I require() a file when using Perl in CGI mode? Do I have to 
modify @INC?


I don't really feel like making it a module, and putting it into Some 
Well Known Location is something I don't feel like even more. It's 
just a supporting file that I want to keep together with the rest of 
the application.




/home/stf/public_html/test/arcv/public_html/../common.pl

I believe the ../ in there may be what's throwing things off.  That 
would probably interpolate as

/home/stf/public_html/test/arcv/common.pl

... which, unless that is indeed where common.pl is located, would 
generate the error you're seeing.


To answer your question, yes, you can absolutely do a require 
"/full/path/to/file.pl" just like that without modifying @INC.

Re: Syntax error in mod_perl but not in shell command

[Michael A. Capone]

I can reproduce this, exactly as he says below.  Some kind of 
incompatibility between mod_perl and the Switch module?


william wrote:


Hello, I am running this code

print "Content-type: text/html\n\n";

use Switch;
$t =1;

switch ($t) {
case 1  { print "number 1\n"; }
}

I have not problem running in shell command
[EMAIL PROTECTED]:/var/www/modperl$ perl test.pl
Content-type: text/html

number 1

But when I ran in mod_perl , I got error
[Thu May 29 14:48:16 2008] [error] syntax error at
/var/www/modperl/test.pl line 6, near ") {"\nNumber found where
operator expected at /var/www/modperl/test.pl line 7, near "case
1"\nsyntax error at /var/www/modperl/test.pl line 8, near "}\n}"\n


Thanks

 



--

-
   C  CableWholesale.com, Inc.
 _ CC   CCP.O. Box 11775 
|  CC   -- m  Pleasanton, CA 94588  
|  CC  888-212-8295o 
|_ CC   == c  1-888-212-8295 Phone   
   CC   CC  CableWholesale .  1-925-455-0808 Fax 
   C  www.cablewholesale.com 
-

Re: mod_perl on Fedora 9

[Michael A. Capone]

Fred Moyer wrote:


Michael A. Capone wrote:


1. Problem Description:

 mod_perl 2.0.4 will not compile on Fedora 9.
`/local/home/swload/webbuild/mod_perl-2.0/src/modules/perl'
make: *** [modperl_lib] Error 2

To be honest, i don't think this is a mod_perl bug per se... it looks 
like a problem with some library not being installed on FC9 that 
mod_perl is expecting to find.  However, mod_perl 2.0.4 compiles just 
fine on FC8.  I originally tried 2.0.4 on FC9, then got the latest 
2.0.5 SVN snapshot, hoping it would be resolved there.


The biggest difference that I see between FC8 and FC9 is the latter's 
use of perl 5.10.



Are you using a fc9 release candidate?  I didn't think 9 was out yet 
(just upgraded to 7 a month ago :o ).  Looks like the official release 
isn't for another 5 days.


http://fedoraproject.org/

I've got a halfway decent modperl testing vm setup (parallels works 
but it crashes infrequently) so I can test this with the fc9 release 
when it comes out.


I am indeed running the latest FC9 release candidate... I honestly 
debated not posting this, since it's technically not appropriate, but I 
have to assume at this stage that the Fedora code isn't going to change 
at this point.


Thanks,
MAC

mod_perl on Fedora 9

[Michael A. Capone]

1. Problem Description:

 mod_perl 2.0.4 will not compile on Fedora 9.

cd "src/modules/perl" && make
make[1]: Entering directory 
`/local/home/swload/webbuild/mod_perl-2.0/src/modules/perl'
gcc -I/local/home/swload/webbuild/mod_perl-2.0/src/modules/perl 
-I/local/home/swload/webbuild/mod_perl-2.0/xs 
-I/local/home/apache/include -I/local/home/apache/include  
-I/local/home/apache/include -D_REENTRANT -D_GNU_SOURCE -DDEBUGGING 
-fno-strict-aliasing -pipe -I/usr/local/include -I/usr/include/gdbm 
-I/usr/lib/perl5/5.10.0/i386-linux-thread-multi/CORE -DMOD_PERL 
-DMP_COMPAT_1X -DLINUX=2 -D_LARGEFILE64_SOURCE -O2 -g -pipe -Wall 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic 
-fasynchronous-unwind-tables -fPIC \

   -c modperl_xsinit.c && mv modperl_xsinit.o modperl_xsinit.lo
modperl_xsinit.c: In function 'xs_init':
modperl_xsinit.c:30: error: 'my_perl' undeclared (first use in this 
function)
modperl_xsinit.c:30: error: (Each undeclared identifier is reported only 
once

modperl_xsinit.c:30: error: for each function it appears in.)
modperl_xsinit.c:30: warning: passing argument 3 of 'Perl_newXS' from 
incompatible pointer type

make[1]: *** [modperl_xsinit.lo] Error 1
make[1]: Leaving directory 
`/local/home/swload/webbuild/mod_perl-2.0/src/modules/perl'

make: *** [modperl_lib] Error 2

To be honest, i don't think this is a mod_perl bug per se... it looks 
like a problem with some library not being installed on FC9 that 
mod_perl is expecting to find.  However, mod_perl 2.0.4 compiles just 
fine on FC8.  I originally tried 2.0.4 on FC9, then got the latest 2.0.5 
SVN snapshot, hoping it would be resolved there.


The biggest difference that I see between FC8 and FC9 is the latter's 
use of perl 5.10.


2. Used Components and their Configuration:

*** mod_perl version 2.05

*** using 
/local/home/swload/webbuild/mod_perl-2.0/lib/Apache2/BuildConfig.pm


*** Makefile.PL options:
 MP_APR_LIB => aprext
 MP_APXS=> /local/home/apache/bin/apxs
 MP_COMPAT_1X   => 1
 MP_GENERATE_XS => 1
 MP_LIBNAME => mod_perl
 MP_USE_DSO => 1


*** The httpd binary was not found


*** (apr|apu)-config linking info

-L/local/home/apache/lib -laprutil-1 -lsqlite3 -lexpat
-L/local/home/apache/lib -lapr-1 -luuid -lrt -lcrypt  -lpthread -ldl



*** /usr/bin/perl -V
Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
 Platform:
   osname=linux, osvers=2.6.18-53.1.6.el5xen, 
archname=i386-linux-thread-multi
   uname='linux xenbuilder2.fedora.redhat.com 2.6.18-53.1.6.el5xen #1 
smp wed jan 16 04:10:44 est 2008 i686 i686 i386 gnulinux '
   config_args='-des -Doptimize=-O2 -g -pipe -Wall 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic 
-fasynchronous-unwind-tables -Dversion=5.10.0 -Dmyhostname=localhost 
[EMAIL PROTECTED] -Dcc=gcc -Dcf_by=Red Hat, Inc. 
-Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux 
-Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads 
-Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db 
-Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio 
-Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly 
-Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto 
-Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto 
-Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin'

   hint=recommended, useposix=true, d_sigaction=define
   useithreads=define, usemultiplicity=define
   useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
   use64bitint=undef, use64bitall=undef, uselongdouble=undef
   usemymalloc=n, bincompat5005=undef
 Compiler:
   cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING 
-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
   optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 
-mtune=generic -fasynchronous-unwind-tables',
   cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING 
-fno-strict-aliasing -pipe -I/usr/local/include -I/usr/include/gdbm'
   ccversion='', gccversion='4.3.0 20080314 (Red Hat 4.3.0-3)', 
gccosandvers=''

   intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
   d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
   ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', 
lseeksize=8

   alignbytes=4, prototype=define
 Linker and Libraries:
   ld='gcc', ldflags =' -L/usr/local/lib'
   libpth=/usr/local/lib /lib /usr/lib
[EMAIL PROTECTED] mod_perl_current]# vi mybugreport

-8<-- Start Bug Report 8<--
1. Problem Description:

 [DESCRIBE THE PROBLEM HERE]

2. Used Components and their Configuration:

*** mod_perl version 2.05

*** using 
/local/home/swload/webbuild/mod_perl-2.0/lib/Apache2/BuildCon