Re: Apache2 + Mod Perl 2.0 + Template Toolkit

[Geoffrey Young]

hi :)

On Tue, Sep 21, 2010 at 5:24 AM, Chris Ray  wrote:
> Hello, I'm currently attempting to update an Apache Cluster from Apache 1.3
> to Apache2. The website served by this cluster uses Template Toolkit
> extensively. It is my understanding that the original Apache::Template
> module doesn't work with Mod Perl 2.0 and that you had started porting a
> version of this plug-in that does?
>
>
>
> Did you finish this? if so where can I get hold of it?

you should definitely ask the mod_perl mailing list about this - I
haven't worked on that in quite a long time.

all that said, what I did do is here

  
http://www.modperlcookbook.org/~geoff/modules/experimental/Apache-Template-2.00_01.tar.gz

though I have absolutely no idea whether it works for the current
version of TT or not.

--Geoff

Re: Security Related BUG within ModPerl 2.0.4

[Geoffrey Young]

William A. Rowe, Jr. wrote:
>> I would like to report a security related bug within ModPerl 2.0.4,
>> though prefer not to disclose the details to  a public channel.
> 
> The appropriate secure channel for all ASF related security vulnerability
> reporting is the closed list, secur...@apache.org, which will be triaged
> to the appropriate committers or committee.

and thanks for treating a potential security vulnerability in a
thoughtful manner.

--Geoff

Re: $r->status no correct

[Geoffrey Young]

Michael Peters wrote:
> Ryan Gies wrote:
> 
>> Below is an Apache log snippet which traces the handler phases for two
>> requests:
>>
>>  A) /scratch/  does NOT have a directory index
>>  B) /scratch/foo/  DOES have a directory index (index.html)
> 
> So here is mine (the text for die() is "A horrible, terrible death!")
> 
> A) /foo/index.pl
> B) /foo/

from mod_log_config.c:

 * %...s:  status.  For requests that got internally redirected, this
 * is status of the *original* request --- %...>s for the last.

for /foo/ the original request is /foo/ and the last request /foo/index.pl.

I'd check your logs but the common log format uses %>s.  try
$r->last->status()

HTH

--Geoff

Re: AC US 2008

[Geoffrey Young]

Philip M. Gollucci wrote:
> Hi All,
> 
> wondering who is going to present at the Apache US 2008 conference in
> New Orleans.
> 
> I'll be there 11/2 - 11/9
> 

I'm presenting on wednesday afternoon:

  http://us.apachecon.com/c/acus2008/sessions/4

--Geoff

Re: mapping URI to filename.

[Geoffrey Young]

Anthony R Fletcher wrote:
> Thanks but that only works for the current request. I was looking for a
> way of translating some other URI to a pathname on the same server.

$r->lookup_uri('/some/uri')->filename()

http://perl.apache.org/docs/2.0/api/Apache2/SubRequest.html#C_lookup_uri_

--Geoff

Re: mapping URI to filename.

[Geoffrey Young]

Anthony R Fletcher wrote:
> Using mod_perl2, is there a way of mapping a URI to a filename or
> directory.
> 
> I can get the root directory for the server and I can append the URI to
> it but this doesn't taking to account aliases, UserDir directives etc.. 
> 
> Any suggestions?

$r->filename()

http://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html#C_filename_

--Geoff

Re: Apache2::Directives trouble with Apache::Test

[Geoffrey Young]

Mark Hedges wrote:

Ugh, I am so flummoxed by this.

How do I get the Apache2::Controller::Directives module to
work from t/conf/extra.conf.in?  Try commenting out the
PerlSetVar for the same named thing and enabling the line to
load the directives and set A2CRenderTemplateDir.

Wacky!  I will buy beer for anyone who can make this work.


use t/conf/extra.last.conf.in

this is documented, but I guess not all that well.

see

  http://www.perl.com/pub/a/2003/07/08/mod_perl.html

on the last page where it explains the difference a bit.  now that you 
know, you can search the archives and I'm sure you'll find a bit of info 
on it.


--Geoff

Re: CPAN tests fail Makefile.PL using Apache::TestMM

[Geoffrey Young]

Mark Hedges wrote:

On Thu, 3 Jul 2008, Fred Moyer wrote:

I've been getting cpan-testers results like this.  What
should I do?  Thanks... --m--

See sub test in:

http://search.cpan.org/src/PHRED/Apache-Dispatch-0.10/Makefile.PL


Wouldn't that Makefile.PL die if mod_perl is not installed,
instead of requiring all libs and then running the tests
with them when they are followed by the CPAN user?

Don't I want it to prompt CPAN to follow dependencies?  But
if I override &test in this way, how then do I run the tests
that need to be run once `make` has begun?

Aha, if I use ModPerl::MM then directives will work, nice.
Thanks!


not all things wanting to use Apache::Test have access to (or want) 
mod_perl - Apache-Test is its own distribution on CPAN, so you might not 
have ModPerl::MM





In short, you override the test target in the Makefile.
I can't take credit for that code as I stole most of it
from Geoff's modules :)


Weird with the package namespace and MY:: and whatnot.  


welcome to ExtUtils::MakeMaker


But
maybe it should just die if it can't require ModPerl::MM. If
you haven't installed mod_perl and you can't figure out what
to do next, maybe you shouldn't install this module.


if mod_perl is a requirement, yes.




I'm trying to abstract a bunch of this dirty work out in
Apache::Bootstrap, but that is primarily geared at dual
life mp1/mp2 modules, so I don't know how this conditional
test code will fit in.


Sounds like a headache! Yeah I have decided I am too lazy to
live in the past while simultaneously trying to keep up.
:-)


this is a Makefile.PL for an Apache-Test-based test suite where mod_perl 
is not required.


http://search.cpan.org/src/GEOFF/WebService-CaptchasDotNet-0.06/Makefile.PL

HTH

--Geoff

Re: Apache::Template for modperl 2

[Geoffrey Young]

Fred Moyer wrote:

Senthil V wrote:

Hi All,

I am trying to install Apache::Template for Apache 2.2.8. 
Whether the porting of Apache::Template is done for modperl  2.
If its done, plz let me know from where i can get the source.


I just took a look at Apache::Template, and it is only for mod_perl 
version 1.


The port to mod_perl 2 looks straightforward, if I can scrape up some 
extra tuits this weekend I might take run at that.


google should have turned up this:

http://www.modperlcookbook.org/~geoff/modules/experimental/Apache-Template-2.00_01.tar.gz

there was quite a bit of conversation about it on the TT list at the 
time, as well as some chatter here.


--Geoff

Re: mod_perl caching problem

[Geoffrey Young]

william wrote:

I like to add on something, I had put the pragma
use strict;
use warnings;

on all modules that I had, but I didn't get the warnings of "Variable
"$foo" will not stay shared at..." .

What other possibility that might cause my program to cache the result
even when the input has already changed ?



http://perl.apache.org/docs/general/perl_reference/perl_reference.html#myScoped_Variable_in_Nested_Subroutines

--Geoff

Re: [MP2]: setting group for a request (require group ...)

[Geoffrey Young]

titetluc titetluc wrote:

Geoffrey, André,
Thank you for your answer.

Conclusion: I will have to:
 . write my own PerlAuthzHandler


yes


 . define a new directive to define my group


no - you can overload the Requires directive.  the example I pointed you 
to shows you how:


  http://www.modperlcookbook.org/code/ch13/Cookbook/AuthzRole.pm

if you return OK or AUTH_REQUIRED the configured httpd authz handler 
will not be run, leaving your PerlAuthzHandler in control of the authz 
phase.


HTH

--Geoff

Re: [MP2]: setting group for a request (require group ...)

[Geoffrey Young]

I would like to use my module in another configuration where group is
checked


PerlAuthHandler  My::Auth
Require group group1



I can not find any mod_perl API method (Apache2::RequestRec::group ?) to set
the group. 


that's right.

you have control over the user via the httpd (and thus mod_perl) API, 
just as the user does via a dialogue box in their browser.  but 
mod_authz_owner maps that user to a group via standard unix gid methods.


I have no idea how this works on win32 ;)


I only found Apache2::RequestRec::require method, but this method
only read the require configuration.

One way to solve the problem is the modify the My::Auth::handler method :

package My::Auth;
sub {
 
 $r->user('getting the user in my module internal structure');
 my $requires = $r->requires;

 # here the code to verify authorization

 return OK;
}

but I think this is a workaround:
 . My::Auth::handler is an AUTHENTICATION handler


yes - is the user who they say they are.


 . the code to verify the AUTHORIZATION should have to be executed by the
httpd core.


exactly :)

your wanting to do something with group is an authz function, not an 
authen function.




How can I manage authorization in this case ?


the 'Require group foo' directive explicity means you want unix user -> 
unix group mapping done in the authz phase.  if you want something from 
this different write your own PerlAuthzHandler.  see recipe 3.16 here


  http://www.modperlcookbook.org/chapters/ch13.pdf

it's mod_perl 1.0 based, but the ideas are the same, and the techniques 
and API nearly identical.


HTH

--Geoff

Re: return value for response handler

[Geoffrey Young]

Torsten Foertsch wrote:

On Tue 10 Jun 2008, John ORourke wrote:

I had a bug with an interesting side effect which I want to understand.

I wanted to redirect the user's browser, and in my response handler I
was setting $r->status(302) but returning Apache2::Const::OK instead of
the correct Apache2::Const::DONE.


return Apache2::Const::REDIRECT



This caused Apache to perform an internal redirect.  Can someone explain
what was happening in terms of handlers and subrequests or point me to
the right doc page?


This is just a guess. So it may be completely wrong. But good old CGI allows 
you to send "Status: 200" along with a Location header to perform an internal 
redirect.


mod_perl does the same if the perl-script handler is used and PerlOptions 
+ParseHeaders. So I'd dig in that direction if that matches your setup. 
Otherwise it is probably an Apache thing.


If you find out what it was tell me, please.


http://www.mail-archive.com/modperl@perl.apache.org/msg04263.html

this thread mentions it a few times

http://www.mail-archive.com/[EMAIL PROTECTED]/msg36041.html

and I explain the internal mechanism here

http://markmail.org/message/hsxqvr37pdvqolgr

and I know I explained this at length dev@ in at least one drawn out 
occasion, but I can't find it at the moment.


HTH

--Geoff

Re: Bug: Character sets and $r->custom_response

[Geoffrey Young]

Clinton Gormley wrote:

Hi all

There seems to be a bug in the mod_perl2/apache2 handling of character
sets for $r->custom_response().  I'm not sure which is at fault.

My pages are all in UTF8, but I can't find a way to set this character
set for custom generated error pages.

I've tried:

 - $r->content_type('text/html; charset = utf8');
 - $r->err_headers_out('Content-type' =>'text/html; charset = utf8');
 - 
 - AddDefaultCharset UTF8

to no avail - apache always overrides this with:

   Content-Type: text/html; charset=iso-8859-1

According to the apache docs for AddDefaultCharset:

Note: This will not have any effect on the Content-Type and
character set for default Apache-generated status pages (such as
'404 Not Found' or '301 Moved Permanently') because those have
an actual character set (that in which the hard-coded page
content is written) and don't need to have a default applied.

That implies that the character set is taken from the file itself, but
that shouldn't apply to errors generated with
$r->custom_response($error_msg)

For now, I plan to just entity escape anything that isn't in the ASCII
range, but is there a workaround? Should this be fixed?


this isn't a mod_perl thing, it's an httpd thing. this is from 1.3:

  http://www.mail-archive.com/[EMAIL PROTECTED]/msg20549.html

it seems the same holds true in httpd 2.0, it seems.  see 
ap_send_error_response in


  modules/http/http_protocol.c

try setting subprocess_env(suppress-error-charset => 1) and see if that 
helps you at all.


--Geoff

[Fwd: HELP-can you help me find MODPERL programmers? in BAY AREA PLEEZE]

[Geoffrey Young]

apparently, due diligence doesn't cover proper spelling or YELLING.  but 
for the interested...


--Geoff

 Original Message 
Subject: HELP-can you help me find MODPERL programmers? in BAY AREA PLEEZE
Date: Tue, 29 Apr 2008 15:29:59 -0500
From: Morse, Patrice <[EMAIL PROTECTED]>


I did my due diligence and discovered you. I am currently trying to find a
MODPERL programmer in the BAY AREA and don't necessarily want to go the
MONSTER route. Are there any chat rooms or ideas you might have??

Thanks

patti



Patti Morse





Patti Morse

IT Staffing Specialist

General Employment / Triad Personnel

455 Market Street, Suite 1170

San Francisco, CA 94105

Voice: 415 357 2000

Fax: 415 357 2020

email: [EMAIL PROTECTED]

Re: Porting Bricolage to mp2: TransHandler Interference

[Geoffrey Young]

Under mod_perl2, however, the same request looks like this:

75749 Apache2::RequestRec=SCALAR(0x29f3300) TransHandler start for 
/workflow/profile/desk/101/101/
75749 Apache2::RequestRec=SCALAR(0x29f3300) TransHandler finish for 
/workflow/profile/desk/101/101/
75749 Apache2::RequestRec=SCALAR(0x29f3300) AccessHandler start for 
/workflow/profile/desk/101/101/
75749 Apache2::RequestRec=SCALAR(0x29f3300) AccessHandler finish for 
/workflow/profile/desk/101/101/

75749 Apache2::RequestRec=SCALAR(0x2a10eb0) TransHandler start for /101/
75749 Apache2::RequestRec=SCALAR(0x2a10eb0) TransHandler finish for /101/
75749 Apache2::RequestRec=SCALAR(0x2a10eb0) CleanupHandler start for /101/
75749 Apache2::RequestRec=SCALAR(0x2a10eb0) CleanupHandler finish for /101/
75749 Apache2::RequestRec=SCALAR(0x734df0) ResponseHandler start for 
/workflow/profile/desk/101/101/
75749 Apache2::RequestRec=SCALAR(0x734df0) ResponseHandler finish for 
/workflow/profile/desk/101/101/




NameVirtualHost *:80

  DocumentRoot   /usr/local/bricolage/comp
  ServerName localhost
  DefaultType"text/html; charset=utf-8"
  AddDefaultCharset  utf-8
  SetHandler perl-script
  PerlResponseHandlerBric::App::Handler
  PerlAccessHandler  Bric::App::AccessHandler
  PerlCleanupHandler Bric::App::CleanupHandler



cleanup handlers are just callbacks run when a memory pool goes out of 
scope.  your test suggests that the memory pool allocated for the 
request is going out of scope before the response handler runs, which is 
odd indeed :)


I'd try these things:

  o use a PerlLogHandler instead of a PerlCleanupHandler

  o push your cleanup from an earlier phase instead of httpd.conf

  o call $r->cleanup_register from an earlier phase instead of pushing 
a  handler


HTH

--Geoff

Re: What happened with Apache2::Reload in mod_perl-2.0.4?

[Geoffrey Young]

Fred Moyer wrote:

Niels van Dijke wrote:

Hi mod_perl maintainers,

Thank you for releasing mod_perl 2.0.4.

I was wondering what happened to Apache2::Reload? Was it missed in
packaging for the upload to CPAN? If so then there may be other files
missing too.


See the Changelog:

Apache2::Reload has been moved to an externally maintained
CPAN distribution

http://search.cpan.org/dist/Apache-Reload-0.10/


hmm...

I can't remember if I knew this or not, but we probably ought to treat 
this like Apache-Test: keep bundling it with releases _and_ maintain 
something separate on CPAN.


so I guess this means a mp2 release should (going forward) include _and_ 
imply a new release of


  o mp2
  o Apache-Test
  o Apache-Reload

--Geoff

Re: [RELEASE CANDIDATE] mod_perl-2.0.4 RC1

[Geoffrey Young]

Philippe M. Chiasson wrote:
The mod_perl 2.0.4 release candidate 1 "Works with Perl 5.10" is ready. 
It can be downloaded here:


http://www.apache.org/~gozer/mp2/mod_perl-2.0.4-rc1.tar.gz


tests fine on my system.

+1

--Geoff

Re: Handing over the POST input to a virtual included part?

[Geoffrey Young]

Torsten Foertsch wrote:

Hi,

is it possible to hand over the POST input of a SSI document to a virtual 
included part of it?


I have an SSI document that contains



This way I can pass parameters that are passed in the URI to the subrequest. 
But how can that be done if the request method is POST? (There is only one 
such part that wants to read the input.)


convert the POST to a GET?  there are docs on the site on how to do this.

--Geoff

Re: ModPerl::MM or ExtUtils::MakeMaker or what?

[Geoffrey Young]

Torsten Foertsch wrote:

Hi,

I am a bit confused about what MakeMaker is best to use with mp2 modules. 
There is the good old ExtUtils::MakeMaker that is mentioned in 
http://perl.apache.org/docs/general/testing/testing.html. How I got there I 
don't remember but I have used in all my modules ModPerl::MM. Is that right? 
Or should I rather port them to use the former?


ModPerl::MM is the way to go.  I suspect you can get away with 
ExtUtils::MakeMaker as log as you're not using XS, but I honestly can't 
recall what additional magic ModPerl::MM adds.  it could be substantial :)




I am asking because I have had FAIL reports from CPAN testers that don't 
install ModPerl::MM. The way around these reports is using


BEGIN {
  eval {
require ModPerl::MM;
require Apache::TestMM;
  };
  if( $@ ) {
warn $@;
exit 0;
  }
  Apache::TestMM->import( qw(test clean) );
}

instead of

use ModPerl::MM ();
use Apache::TestMM qw(test clean);

This way no Makefile is written and the automatic test suite is happy.


yeah, that's the way you'll need to do it... if you care about those 
reports :)


you can probably assume that if the user has ModPerl::MM that 
Apache-Test is available.


--Geoff

perl at apachecon

[Geoffrey Young]

hi all :)

perl's (and mod_perl's) presence at apachecon has been dwindling over 
the years.  I won't get into a rant about why this might be, so please 
don't you do it either :)


anyway, if you have any interest in attending apachecon us this year, 
please login to the apachecon site and take the time to rate the current 
proposals - showing interest in perl ones is the only voice we have 
toward getting them chosen for the conference.


  http://apachecon.com/html/login.html

anyone can create an account (and if you go to the conference you'll 
need to create one to register anyway).


the main site is

  http://www.us.apachecon.com/us2008/

and the dates are november 3-7 in cool new orleans.

thanks

--Geoff

Re: utf8 urls

[Geoffrey Young]

John ORourke wrote:

Eli Shemer wrote:


For some reason the following test doesn’t print anything out to the 
screen


Do I need to change something in the apache configuration, or 
mod_perl’s ?


 


/articles_read.pl?id=חוזרת

 


## get http parameters

$r = shift;

$apr = Apache2::Request->new($r);

print  $apr->param('id');



I'm not sure why you get nothing, but I can tell you strings read from 
Apache objects come through as octets and need to be decoded before 
use.  We're using UTF-8 chars in URLs but I've never used one in a GET 
request parameter.


I can't say why it doesn't work, but I'm surprised it would in either 
case - the only characters explicitly allowed in a uri are us-ascii. 
from rfc2396:


  2.4. Escape Sequences

   Data must be escaped if it does not have a representation using an
   unreserved character; this includes data that does not correspond to
   a printable character of the US-ASCII coded character set, or that
   corresponds to any US-ASCII character that is disallowed, as
   explained below.

I bit of googling turned up this cpan module:

  http://search.cpan.org/dist/URI-Find-UTF8/lib/URI/Find/UTF8.pm

where the docs point to a ja.wikipedia.org page.  for me (firefox 2.0) 
clicking on the "original" uri (the one with the japanese characters) 
opens up a uri with the uri-escaped character sequence.  it's like magic ;)


anyway, my point wasn't to get into some huge debate on whether people 
are (successfully) using utf-8 characters in uris, etc.  rather, it is 
that mod_perl is (mostly) merely a wrapper around apache, and if 
something is improper wrt an official rfc apache generally dismisses it 
rather than bending to a behavior which people may be using anyway.


so, if it works, great.  if not, try making your urls conform to 2396 
and see if you have better results.


--Geoff

[Fwd: Call for Papers Opens for ApacheCon US 2008 (pls forward)]

[Geoffrey Young]

 Original Message 
Subject: Call for Papers Opens for ApacheCon US 2008 (pls forward)
Date: Sat, 01 Mar 2008 21:49:34 -0500
From: Shane Curcuru <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]

Help drive more CFP submissions - send this to your users@ lists to help
drive awareness.  Thanks!
- Shane


Call for Papers Opens for ApacheCon US 2008

!REMINDER: this will be a short CFP, ending on 3 April, so please be
sure to get your CFP submissions in soon!

The Apache Software Foundation (ASF) invites submissions to its official
users' conference, ApacheCon US 2008, held 3 November through 7
November, 2008 at the Sheraton New Orleans.  ApacheCon serves as a forum
for showcasing the ASF's latest developments, including its projects,
membership, and communities.  ApacheCon offers unparalleled educational
opportunities, with dedicated presentations, hands-on trainings, and
sessions that address core technology, development, business/marketing,
and licensing issues in Open Source.

The conference program includes competitively selected presentations,
trainings/workshops, and a small number of invited speakers. All
sessions undergo a peer review process by the ApacheCon Conference
Planning team.

With the great success of ApacheCon US 2007, we are excited to move to
New Orleans in 2008.  We're proud to announce that we are going to
intensify and deepen the pre-conference trainings by offering 2-day
trainings alongside full- and half-day trainings, and each training
session will have certifications of completion for those who fulfill all
the requirements of the training.

The ASF comprises some of the most active and recognized developers in
the Open Source community.  By bringing together the pioneers,
developers, and users of flagship Open Source technologies, ApacheCon
provides an influential platform for dialogue, between the speaker and
the audience, between project contributors and the community at large,
traversing a wide range of ideas, expertise, and personalities.

ApacheCon welcomes submissions from like-minded delegates across many
fields, geographic locations, and areas of development.  Please note you
do not need to be committer or project contributor at the ASF to submit
a proposal!  The unique nature of the Apache community lends itself to
creating a conference content that is not only the best of Open Source
but cutting edge as well.

Conference Themes and Topics

* Apache HTTP server topics: installation, configuration, migration
* ASF-wide projects such as, Jakarta, Tomcat, Maven, Geronimo,
  Harmony, Lucene, SpamAssassin, Portals, and Web Services
* Scripting languages and dynamic content such as Java, Perl, Python,
  Ruby, XSL, and PHP
* Security and e-commerce
* Performance tuning, load balancing and high availability
* New technologies and initiatives such as Web Services and Web 2.0
* ASF-Incubated projects such as Abdera, CXF, and Qpid
* Case studies and industry profiles demonstrating the use of Apache
  software
* Open source community and business models, legal and marketing
  issues

NOTE: Marketing-oriented submissions aimed at promoting specific
organizations or products will not be accepted.


Submission Guidelines

Submissions must include title; speaker's name with affiliation and
email address; format (Training vs. General Session) and duration
(1-hour general session, or half-, full-day, or two-day training);
expertise level (beginner to advanced); a full description including
abstract and objectives (200 words or less);  intended audience and
maximum number of participants, with background knowledge expected of
the participants (Trainings only); and speaker bio (100 words or less).
  Full presentation and training materials will be due at a later
date, as noted below.

Types of Submissions: Trainings, General Sessions, Case Studies and
Industry Profiles.

Speakers whose proposals are accepted have registration fees waived,
reasonable travel and part of their lodging expenses paid.  Only one
speaker will be covered per accepted proposal.


Important Dates

Proposal submission deadline:  3  April, 2008 *Before* ApacheCon Europe!
Notification of acceptance:25 April, 2008
Materials for Web site:3  October, 2008
Materials for Trainings:   17 October, 2008
Conference Date:   Monday to Friday, 3-7 November 2008
Trainings: Monday and Tuesday, 3-4 November 2008
General Sessions:  Wednesday to Friday, 5-7 November 2008


To submit your completed proposal, please follow the directions to logon
here to the existing ApacheCon CFP system:
   http://www.us.apachecon.com/us2008/

Use your existing ApacheCon CFP login, or create a new one as needed.
Then under ApacheCon US 2008 Status and Options, click the "Fill out a
CFP form" link.

If you are not yet subscribed to the ApacheCon announcement mailing
list, send an email message to [EMAIL PROTECTED]


About ApacheCon 

Re: return DECLINED or OK?

[Geoffrey Young]

J. Peng wrote:

At what cases should we return a DECLINED or a OK from a handler?
I saw the handler of PerlTransHandler returns a
Apache2::Const::DECLINED but dont know why.


see the introduction to part III here:

  http://www.modperlcookbook.org/chapters.html

in general, trans handlers return DECLINED because they don't typically 
do sufficient mapping of a uri to a resource on disk - they usually 
alter the uri then let the default apache trans handler do the mapping.


--Geoff

Re: Amazon

[Geoffrey Young]

Jonathan Vanasco wrote:
I've heard from a few reputable sources that Amazon is looking to drop 
mod_perl, and push into another technology ( which I've also head is 
likely to be Java ).


I always thought amazon was a good argument for perl but not mod_perl - 
last time I looked they were using mason + fastcgi (not mod_perl)


--Geoff

Re: Apache::DProf giving empty tmon.out files

[Geoffrey Young]

Ok, just tried putting it in there, didn't seem to make any difference to
the tmon output (naturally, checking after stopping the server). I had
noticed a reference to APR::Pool in the tmon files before so I would have
thought it was loading it in any case.


if you want to (again) try Devel::Profiler it's really as simple as adding

  use Devel::Profiler::Apache;

to your startup.pl.  see the t/conf/ files in the D::P (svn) 
distribution for a working example (assuming it passes the tests :)


you also need to start in single server mode or, alternatively, setting 
these


  MinSpareServers  1
  MaxSpareServers  1
  StartServers 1
  MaxClients   1
  MaxRequestsPerChild  0

at the bottom of your httpd.conf.  note also that you can set the output 
directory via


  Devel::Profiler::Apache->import(output_dir => $odir);

in your startup.pl.  see also

  http://use.perl.org/~geoff/journal/34562

for a list of packages to avoid.

lastly, it's been noted already, but in case you missed it, please note 
that you won't get any data until the child process exits (or httpd is 
shut down), so try killing off the child.


fwiw, I submitted a proposal for OSCon on profiling, specifically how we 
profile "a large mod_perl application" :)  hopefully the selection folks 
find it a worthy topic.


--Geoff

Re: Apache::DProf giving empty tmon.out files

[Geoffrey Young]

Alx G wrote:

Hi,

I'm trying to use Apache::DProf with my Perl web app. I can't work out what
I'm doing wrong - it should be working but it isn't (how many times have we
all said that to ourselves eh?).

I've run out of options to try now, I hope someone can help me please.


try Devel::Profiler:

  http://search.cpan.org/dist/Devel-Profiler/

you might want to try the svn sources, since it's been a while since 
there has been a release


  http://sourceforge.net/projects/devel-profiler/

--Geoff

Re: Apache::Test @var@ substitution

[Geoffrey Young]

Torsten Foertsch wrote:

Hi,

I have looked through http://perl.apache.org/docs/general/testing/testing.html 
for a list of variables available for @@ substitution. After that I thought 
the best documentation is the code and found in TestConfigParse.pm this 
function:


sub apply_take1 {
my($self, $c, $directive) = @_;

if (exists $self->{vars}->{lc $directive}) {
#override replacement @Variables@
$self->{vars}->{lc $directive} = $c->{$directive};
}
else {
$self->spec_add_config($directive, qq("$c->{$directive}"));
}
}

Am I right that all variables from $self->{vars} can be used in @@ 
substitution? The next step would be to look a t/conf/apache_test_config.pm 
which variables that are.


I actually had the exact same question last week.  it is documented in 
Apache::TestConfig, but I'll admit it's not an intuitive place to look 
(nor are the steps suggested there very welcoming).  grep for 'Special 
Placeholders' in TestConfig.pm




Wouldn't it be better to have a list with a short explanation in the 
testing.html document?


patches welcome, of course.



My actual question was whether I can use @[EMAIL PROTECTED] I think the answer is yes 
but the way to get it is too complicated.


yes, and yes :)

I was actually looking to use src_dir, which apparently caused things to 
blow up - the substitution code dies when you use a variable that isn't 
defined.  I started looking into fixing it but, well, other things 
happened :)


--Geoff

Re: PerlFixupHandler - %ENV

[Geoffrey Young]

Anthony Gardner wrote:

I'm trying to write a FixupHandler to clean up the query_string
before it gets to the response phase. Problem is, I can't. After
cleaning it up, I reassign to $ENV{QUERY_STRING} but in the called
response script, the original QUERY_STRING is present.

I can add new keys to %ENV at the PerlFixupHandler stage and they're
made available to the called response script, but not the changed
QUERY_STRING!!

Any pointers would be great.Thx


try calling

  $r->subprocess_env();

in a void context.  see

http://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html#C_subprocess_env_

HTH

--Geoff

Re: Perl 5.10

[Geoffrey Young]

John Siracusa wrote:
> On 12/21/07 2:32 AM, Andreas J. Koenig wrote:
>> I fear I do not understand enough of mod_perl to volunteer to make a
>> release.
> 
> Me neither, but have you at least contacted the mod_perl maintainers about
> this?  Perhaps you could file a bug on rt.cpan.org even?

the current maintainers hang out here :)

we'll try to roll a mp1 release soonish, which should address 5.10
issues.  with the holidays it might be difficult, but hopefully it won't
take too long after the new year.

--Geoff

Re: Missing HTTP Headers

[Geoffrey Young]

> Client-Transfer-Encoding: chunked  <-- **missing from below**

> Content-Length: 123434  <-- **missing from above**

you don't need a Content-Length header of your client uses a chunked
transfer encoding, so these two are kinda mutually exclusive.
fortunately, you also don't need to know that - these are both headers
that apache sets for you when it generates the response.

it doesn't address your cookie issue, but you don't need to worry about
these headers in particular.

--Geoff

Re: GATEWAY_INTERFACE CGI-Perl

[Geoffrey Young]

> If there is a syntax error with the  then I'd
> appreciate it if someone could explain what it is and how to correct it
> (likewise with any conflicts).

I don't see the problem at first glance, but what you're asking apache
to do is odd here -  generally refers to a uri path component
(/foo/bar/) while  refers to a filename (/foo/bar/baz.pl).  so,
I'd rather see something like

  

see

  http://httpd.apache.org/docs/2.2/sections.html

for a better explanation, specifically the "What to use When" section.

HTH

--Geoff

Re: Auth Question need some input

[Geoffrey Young]

Alexander Burrows wrote:
...
> I gave this a shot with the little bits I could find on
> the net and I can not seem to get it working. I have ordered the mod_perl
> cookbook but have not received it yet.

  http://www.modperlcookbook.org/chapters/ch13.pdf

> 
> I just tried a very basic one to start with that would check a cookie and
> redirect you to a login page if it was not there. The redirect would not
> work and I would get a forbidden message from the server.

you can't really return REDIRECT here, as you've discovered.  what you
need to do is return FORBIDDEN and couple that with a custom dynamic
ErrorDocument via $r->custom_response().  see recipe 13.7 in the
cookbook/above pdf.

HTH

--Geoff

Re: Hook Ordering

[Geoffrey Young]

David Eisner wrote:
> We have a section of our website that is protected by Basic
> username/password authentication.  I've been asked to setup a system
> where, once successfully authenticated, users are taken to a legal
> agreement page which they are asked to accept before they can continue
> to the page they requested.
> 
> I'm using mod_perl 2.0.3 to implement this.  The basic system now
> works.  I have a PerlAccessHandler installed for the protected portion
> of the site, which checks for the presence of an "ACCEPT_LA" cookie.
> If the cookie is not set, the user is redirected to a form with the
> agreement and "I Agree" / "I Do Not Agree" buttons.  If they agree,
> the ACCEPT_LA cookie is set and they are redirected to the page they
> originally requested.
> 
> The only problem right now is that when visiting a URL in the
> protected part of the site, the user *first* gets taken to the legal
> agreement, and if they accept it, they are *then* asked to login.  The
> desired behavior is that the user first gets the Basic AuthType
> username/password dialog, and if they successfully login, then they
> get taken to the agreement page.

use a PerlAuthzHandler instead of a PerlAccessHandler for your ACCEPT_LA
check :)

> 
> How can I change the ordering of the handlers to achieve this?  I
> checked the documentation and it seems incomplete, indicating that
> Hook Ordering is "not working."  [1]  Is that the end of the story?
> 
> Thanks.
> 
> -David
> 
> [1] 
> http://perl.apache.org/docs/2.0/user/handlers/intro.html#Hook_Ordering__Position_

dynamic hook ordering requires changes to httpd, so I don't think this
will ever happen.  sorry.

--Geoff

Re: [RELEASE CANDIDATE] Apache-Test-1.30 RC1

[Geoffrey Young]

Andy Armstrong wrote:
> On 16 Nov 2007, at 16:33, Fred Moyer wrote:
>> A release candidate for Apache::Test is now available:
>>
>> http://people.apache.org/~phred/Apache-Test-1.30-RC1.tar.gz
>>
>> Please take a moment to download, build, and report test failures or
>> success back to the list.  Thanks!
> 
> 
> I see you're using Test::Harness::Straps. We've just recently deprecated
> straps in favour of the new interface provided by TAP::Harness:
> 
> http://search.cpan.org/~andya/Test-Harness-3.03/lib/TAP/Harness.pm
> 
> I'm not sure how heavy your dependence on Straps is - but you might find
> the new interface easier to work with.

I'm pretty sure that the only place we use straps is for the php
interface.  but yeah, I know about the migration (and even mentioned our
needs on perl-qa ;) and I plan on migrating "soonish"

--Geoff

Re: mp 2.0.3 make test fails against httpd trunk: Has authorisation changed since httpd 2.2 ?

[Geoffrey Young]

Rolf Banting wrote:
> Thanks for the replies.
> 
> I'll carry on and see if I can get to the bottom of the other make
> test failures. At that point I'll seek advice on whether or not the mp
> archive needs an update.
> 
> I've moved on to access2.t now. The difference with access.t is that
> user id authentication is required. No matter what I try my response
> always starts off:

according to the httpd devs here at apachecon, the way Require behaves
has changed "recently" (since january ;)  I'm not exactly sure how the
behavior changed, though.

I'll try and look into this next week...

--Geoff

Re: mp 2.0.3 make test fails against httpd trunk: Has authorisation changed since httpd 2.2 ?

[Geoffrey Young]

Rolf Banting wrote:
> I can answer my own question, at least in part.
> 
> In the t/httpd.conf  location /TestAPI__access has AuthType none and
> AuthName modperl defined. If I comment those out t/api/access.t passes
> except for test 7. Test 7 expects 'none' as AuthType whereas in fact
> it is 'undef' now.
> 
> I've looked through the server 1.3,2.0, 2.2 & dev documentation. They
> all say that there are 2 possible values for AuthType - Basic or
> Digest. 

those are the two default values handled by the included httpd
authentication handlers.

you can absolutely define any AuthType you want if you intend on writing
a new, fully implemented authen handler in mod_perl - httpd will only
balk if you don't write the handler properly and control ends up being
passed to httpd proper (the mod_perl authen handler will supersede httpd).

> From my apache/mp novice perspective it looks as though
> access.t really should also fail for mp vs 2.2.6 since 'none' does not
> appear to a legal AuthType.

nope, this definitely works on 2.2.6.  something in trunk must have
changed that removes capabilities provided since 1.3.

> 
> Anyway - should access.t & t/conf/httpd.conf in the mod_perl trunk be
> changed? I am quite happy to do this.

I don't think it's that simple.  first, this is httpd-trunk - we ought
to figure out whether this change is intended, part of a work in
progress, or just a mistake.  after that we can figure out how to handle it.

--Geoff

Re: OffTopic (slightly) - Module Feedback Wanted - Authen::Ticketless

[Geoffrey Young]

> That being said -
> i. i'd like to explore Digest Access more, as a replacement for
> CRAM-MD5

a long time ago I thought that you could use the nonce in digest auth to
provide this kind of thing:

  http://search.cpan.org/dist/Apache-AuthDigest/Session/Session.pm

fwiw

--Geoff

Re: simple profiling capability

[Geoffrey Young]

E R wrote:
> Hi,
> 
> I have the need for a simple profiling capability for mod_perl applications.
> At a few (< 50) points in my code I want to call something like:
> 
> $profiler->mark("some identifier");
> 
> and increment the counter for "some identifier". Later I want to be able to 
> get
> (through a web page) a summary (grouped by identifiers) of all the
> profiling calls
> made (of course, made by all Apache child processes.) For instance, if I want
> to profile the number of times a particular subroutine was called, I would 
> use:
> 
> sub mysubroutine {
>   $profiler->mark("in mysubroutine");
>   ...
> }
> 
> This is very similar to logging, except for the summary part. Does anyone
> have ideas of a good way to implement this? Shared memory? An external
> daemon to record these calls? Has someone already implemented this?
> Robust and simple are good.

this should help:

http://search.cpan.org/dist/Devel-Profiler/lib/Devel/Profiler/Apache.pm

--Geoff

Re: DirectoryIndex

[Geoffrey Young]

Marilyn Burgess wrote:
> Hello,
> 
> I'm running modperl2 on Debian from the libapache2-mod-perl2 debian package
> and I can't get the DirectoryIndex rule to work properly. I have the line
> 
> DirectoryIndex index.html index.cgi index.pl index.php index.xhtml
> 
> in apache2.conf, and in the file default in sites-available... nether seem
> to have any effect as I get the error: "Attempt to serve directory:" .
> correct doc root.
> 
> I have found this post http://www.wlug.org.nz/SargeApache2Notes that
> explains that this is a "bug" and directs me to a dead blog. Does anyone out
> there know a work around or a fix that has worked for you?

that site links to a broken mail list archive, so you could search other
public archives around that time for the same thread.  or, of course,
google is your friend :)

you may find this helpful:

  http://marc.info/?l=apache-modperl&m=112808685415719&w=2

--Geoff

Re: mod_perl Apache2 RequestRec allowed problem

[Geoffrey Young]

Christopher Stanton wrote:
> I am trying to set the allowed bitmask in a custom request handler
> when I receive the OPTIONS method (and when I receive a method request
> for a method I do not support).
> 
> I have followed the example in
> http://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html#C_allowed_
> but Apache always returns "Allow: GET,HEAD,POST,OPTIONS,TRACE" in the
> header irrespective of what options I set.
> 
> For example, lets say I only accept PUT to try to restrict the
> available options to OPTIONS, TRACE, and PUT.
> 
> I have tried both
> $r->allowed($r->allowed | (1<< Apache2::Const::M_PUT));
> and
> $r->allowed(1< with a return of Apache2::Const::DECLINED in either case in my handler.
> 
> Neither ends up modifying the supported options sent to the client.
> 
> In tha handler if I print the return value of $r->allowed:
> print $r->allowed(1< print $r->allowed() . "\n";
> return Apache2::Const::DECLINED;
> 
> I get:
> 1
> 2
> 
> So the record is being updated, but for some reason Apache is not
> basing its response to the client off of the record.
> 
> Can anyone provide any insight into why I am unable to modify the list
> of request methods my handler is capable of servicing?

the Allow header appears to be built not from r->allowed but
r->allowed_methods->method_mask.  so, try this:

http://perl.apache.org/docs/2.0/api/Apache2/Access.html#C_allow_methods_

HTH

--Geoff

Re: mod_rewrite is working strangely while using mod_perl

[Geoffrey Young]

> as a workaround, please try adding
> 
>   $r->subprocess_env();
> 
> before you examine %ENV.  it should force re-population of %ENV from the
> subprocess_env table, which is where mod_rewrite stashes it's stuff.

a few other things as well...

your provides is running mod_perl on win32?  that's odd for a
provider... but please report back the version of mod_perl they are running.

also, if any of the win32 developers could give my new test a whirl,
that would be great.  the odd thing about this is that the variable
itself is there but the value is undef - I would expect that it would
either be missing entirely or picked up properly...

--Geoff

Re: mod_rewrite is working strangely while using mod_perl

[Geoffrey Young]

Marco Bretschneider wrote:
> Hi again,
> 
>> please explicitly add
>>
>>   +SetupEnv
>>
>> to your PerlOptions under /folder
> 
> added this option - same effect.
> 
>> so, I'd like you to try a few things...
>>
>> first, please verify that this is not a problem with mod_cgi as well.
>> that is, take your same setup, but use
>>
>>   SetHandler cgi-script
>>
>> for your test and see if the problem persists.  if mod_cgi does the
>> right thing then I'll look into it further.
> 
> it turns out, that we do not have this problem using mod_cgi. So, I guess 
> it's worth to have a closer look at it ;-)

as a workaround, please try adding

  $r->subprocess_env();

before you examine %ENV.  it should force re-population of %ENV from the
subprocess_env table, which is where mod_rewrite stashes it's stuff.

--Geoff

Re: mod_rewrite is working strangely while using mod_perl

[Geoffrey Young]

Marco Bretschneider wrote:
> Hi,
> 
> I reported a bug that seems to be related to mod_rewrite of apache.
> It turns out, that the problem only occurs while using mod_perl.
> Note, that everything else is working fine with mod_perl. Anyway I'm
> not quite sure where this bug belongs to (mod_perl or mod_rewrite). I
> was asked to report a bug to your list too. Please have a look at
> 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=43514

please explicitly add

  +SetupEnv

to your PerlOptions under /folder

fwiw, I just added a test for this to the mod_perl svn sources - it's
not an .htaccess-based test but it does show env variables coming through.

for the most part, the env communication between mod_rewrite and anyone
else (mod_perl, mod_cgi, whomever) is pretty simple and clear -
mod_rewrite populates the subprocess_env table, then mod_cgi or mod_perl
calls a core apache API to populate %ENV at content-generation time.

so, I'd like you to try a few things...

first, please verify that this is not a problem with mod_cgi as well.
that is, take your same setup, but use

  SetHandler cgi-script

for your test and see if the problem persists.  if mod_cgi does the
right thing then I'll look into it further.

--Geoff

Re: Turning off caching

[Geoffrey Young]

Ian G. Tyndall wrote:
> Thanks for the quick responses!
> 
> For argument sake, I went ahead and added the following to the top of
> one of the problem scripts:
> 
>  my $r = shift;
> $r->no_cache(1);
> 
> And it didn't fix it.

if that didn't work then you might be experiencing variable sharing
problems, not caching of the http sort.  see

http://perl.apache.org/docs/1.0/guide/porting.html#Description
http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Remedies_for_Inner_Subroutines

which applies to both mod_perl 1 or 2 wrt Registry.pm

HTH

--Geoff

Re: mod_perl success stories on ZDNet

[Geoffrey Young]

Boysenberry Payne wrote:
> If I have my own success story how would I go about adding it to the list?

I think you can just email your success story to the list.  then someone
with sufficient karma can add the email into


http://svn.apache.org/repos/asf/perl/modperl/docs/trunk/src/outstanding/success_stories/

twiddle a few bits, and it will get integrated into the site.

--Geoff

Re: Turning off caching

[Geoffrey Young]

Ian G. Tyndall wrote:
> I've got an existing cgi project that I was hoping to get some
> performance improvements from mod_perl. Everything was going great until
> I ran into a caching issue. The script repeatedly performs the last
> action given regardless of the paramaters passed in.
> 
> I've seen this:
> 
> $r->nocache(1);
> 
> But, how can I use it in my startup.pl or in my httpd.conf?

you can't - the $r means it's a per-request thing, not a
lifetime-of-the-server thing

> If I can't do it in the startup.pl, or the conf file, I would welcome
> any other recommendations.

see mod_expires:

  http://httpd.apache.org/docs/2.0/mod/mod_expires.html

HTH

--Geoff

Re: Q: Build.PL/Makefile.PL, and CPAN testers...

[Geoffrey Young]

Fred Moyer wrote:
> Graham TerMarsch wrote:
>> Wanted to ping the list about something that's irked me the last few
>> days...
>>
>> After recently releasing Apache2::Filter::Minifier::JavaScript/CSS, I
>> saw several failed CPAN testers reports, generally due to the tester
>> not having the required modules on their machine.
> 
> I can't speak too well to the Module::Build problems, but I learned a
> great deal from following Geoff's lead on some of his modules.  Take a
> look at:
> 
> http://search.cpan.org/src/GEOFF/WebService-CaptchasDotNet-0.06/Makefile.PL
> 
> for a good example of how to handle whether or not Apache::Test is
> present.  If Apache::Test isn't present, then the tests don't run, which
> is what you want.  The philosophy there is that you can still install
> the module if you don't have the dependencies required for the test,
> which is an issue sometimes (production environments for example).
> 
> Geoff can speak to this problem a lot better than I can, everything I
> know about this stuff I owe him for responding to my pestering when I
> was making Apache::Dispatch mp2 compatible.

sorry, I got a private copy of this email and responded to that instead
of on list :)

in the end, what graham seemed to want was a variant of this:

  http://search.cpan.org/src/GEOFF/Apache-Clean-0.05/Makefile.PL

which simply skips over the test phase if $testing_infrastructure_module
isn't available.  in this example I want Apache::Test, but I've also
used it to scan for $version of Test::Builder or whatever.  outside of
test infrastructure modules, you can/ought to handle other dependencies
in the test files themselves.

graham's module has the additional overhead of using ModPerl::MM to make
the basic WriteMakfile() call, for which he has a solution I'll let him
share :)  but most modules don't suffer from that.

--Geoff

Re: RFC: Apache2::Filter::Minifier::JavaScript

[Geoffrey Young]

Graham TerMarsch wrote:
> On Thursday 20 September 2007 6:45 am, Geoffrey Young wrote:
>> Graham TerMarsch wrote:
>>> I've been working on some projects needing JS minification recently and
>>> wanted to ping others and find out if anyone else would find it useful to
>>> have a mod_perl2 filter that auto-minified your JS (using
>>> JavaScript::Minifier)...
>> see also
>>
>>   http://search.cpan.org/src/GEOFF/Apache-Clean-2.00_7/
>>   http://www.perl.com/pub/a/2003/04/17/filters.html
> 
> I'd seen HTML::Clean before, and had considered making a separate minifier 
> module along those lines.  I actually hadn't seen that version of it, though; 
> I missed the dev releases.
> 
> Thanks for the pointer though Geoff, I'll have a look at the latest 
> Apache::Clean release and see what useful tidbits of info are in there that 
> I've missed.

the parts you'll be interested in are the parts you were asking about,
like only running for a specific content-type.  it also has a basic
framework for using the streaming filter API and dealing with filter
context, as well as handling http compliance (removing the
content-length header, for example).  in all, you ought to be able to
use the base of it and swap the HTML::Clean innards for the purifier of
your choice.

good luck.

--Geoff

Re: RFC: Apache2::Filter::Minifier::JavaScript

[Geoffrey Young]

Graham TerMarsch wrote:
> I've been working on some projects needing JS minification recently and 
> wanted 
> to ping others and find out if anyone else would find it useful to have a 
> mod_perl2 filter that auto-minified your JS (using JavaScript::Minifier)...

see also

  http://search.cpan.org/src/GEOFF/Apache-Clean-2.00_7/

  http://www.perl.com/pub/a/2003/04/17/filters.html

HTH

--Geoff

Re: intermittent import errror from Apache2::RequestUtil

[Geoffrey Young]

> 
> SD  (sure does)

:)

fwiw, the "don't export anything" syntax (that is, the empty list) will
actually save you a bit of memory, as nothing will be exported into the
current namespace.  that's why you see that syntax all over the mod_perl
docs as a best practice.

> 
> Out of curiosity, why would my mistake not cause an error every time it runs?

no idea :)

--Geoff

Re: intermittent import errror from Apache2::RequestUtil

[Geoffrey Young]

Charlie Katz wrote:
> Hi,
> 
> After some recent development work that included installing some new modules, 
> I'm suddenly seeing an intermittent import error:
> 
>   "document_root" is not exported by the Apache2::RequestUtil module
> 
> This comes of course from the line
> 
>use Apache2::RequestUtil 'document_root';

the only reason to use that syntax would be so that perl knows which
method to call when you use document_root() by itself without a class or
package qualifier.  which, of course, is quite meaningless, as you need
a request object to make document_root() do anything.

so, change that to

  use Apache2::RequestUtil ();

and those random errors will go away and  everything will continue to
work at least as well as it used to :)

HTH

--Geoff

Re: Disconnection from basic auth

[Geoffrey Young]

Matthieu FEREYRE wrote:
> I use a basic authentification (Apache2::Access) wich works fine, but my 
> question is :
> How do I disconnect users ?

the short answer is that you can't.  this is why you don't see popup
authentication anywhere anymore :)

try a simple module like Apache::AuthCookie:

  http://search.cpan.org/dist/Apache-AuthCookie

read through the pod in AuthCookie.pm and you'll find:

"When you determine that the client should stop using the
credentials/session key, the server can tell the client to delete the
cookie. Letting users "log out" is a notoriously impossible-to-solve
problem of AuthBasic."

HTH

--Geoff

Re: modperl and fprintf(stdout,...)

[Geoffrey Young]

Manoj Bist wrote:
> Hi,
> 
> I would really appreciate if someone could answer the following question
> regarding modperl and writing to stdout for me:
> 
> I have a perl binding for a C library which generates binary(audio/video)
> data.  To push this binary data over an HTTP response, fprintf(stdout,...)
> does not work in context of modperl.
> Do I have to copy the binary data to a perl scalar variable and then do
> $r->print(...) in the perl script?

if your binding is in XS you can just use the apache API directly from
your XS module.  something like ap_send_fd() should do the trick if you
have an open fd.  otherwise you'll need to write out buckets in httpd
2.x or use another raw means of streaming the response across the wire.

but to the root of your question, no, you shouldn't need to copy the
data once you have it, provided you work from within XS - use use the
httpd api, for which there are many examples in the httpd distribution
(choose one of the generator modules, like cgi or something).

HTH

--Geoff

Re: practical mod_perl

[Geoffrey Young]

Luke Lu wrote:
> Hi all
> 
>Anyone who has the  (chm/pdf), please give me a
> copy.

http://www.modperlbook.org/

--Geoff

Re: Using bytes_sent in mod_perl2

[Geoffrey Young]

>>> unless (exists $ENV{MOD_PERL}
>>> ? Apache2::RequestUtil->request()->bytes_sent()
>>> : tell STDOUT)
>>> {
>>> #... send response headers
>> since you no longer send response headers in mp2, isn't this all moot?
> 
> Did you overlook the fact that I'm running all this through
> ModPerl::Registry, or am I overlooking something?

no, I didn't overlook it.  but I did forget you said it was in
mod_cgi-compat mode - I haven't thought in those terms in years :)

still, you can't bee in full CGI mode if you're making mod_perl API
calls like $r->bytes_sent,  in which case...

in mp1 the idiom was this

  $r->send_http_header('text/html');
  print $content;

but note that the 'text/html' part is just calling $r->content_type() as
a convenience.  so the above is equivalent to

  $r->content_type('text/html');
  $r->send_http_header();
  print $content;

in mp2 we don't need to worry about the headers, as the header filter
does all the work, so it looks like this

  $r->content_type('text/html');
  print $content;

so, if you are able to change your

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

and like lines to equivalent mp2 API calls you should be ok.

of course, none of this addresses your original bytes_sent() problem,
but that's probably because I've never seen it used that way, even in
the days of old.

does this help?

--Geoff

Re: Using bytes_sent in mod_perl2

[Geoffrey Young]

Steve Hay wrote:
> I'm in the process of converting some old software from mod_perl1 to
> mod_perl2, and I'm finding that $r->bytes_sent() doesn't work as it used
> to.

yeah.  IIRC the issue is that now we have filters, so in order to
actually calculate bytes_sent() the filters need to run in their entirety.

> 
> The code is written in a very out-moded style: it is compatible with
> mod_cgi, runs via ModPerl::Registry (formerly Apache::Registry), and
> produces all its output via explicit print() statements scattered left,
> right and centre, including a print() statement to send the response
> headers. An error-handling subroutine calls $r->bytes_sent() to find out
> if anything has been sent yet, so that it knows whether or not it needs
> to send response headers before sending an error page (it could be
> invoked either before or after the headers have been sent in the normal
> course of events).
> 
> This works fine under mod_perl1, but under mod_perl2 I find that the
> error-handler always emits response headers itself (i.e. it always
> thinks that nothing has been sent yet). Therefore, in those cases where
> response headers have already been sent, I now have a second set being
> sent, which the user ends up seeing in the web browser. The code in
> question is simply:
> 
> unless (exists $ENV{MOD_PERL}
>   ? Apache2::RequestUtil->request()->bytes_sent()
>   : tell STDOUT)
> {
> #... send response headers

since you no longer send response headers in mp2, isn't this all moot?

> }
> #... send error page
> 
> There is a suggestion in
> 
> http://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html#C_bytes_sent
> _
> 
> that bytes_sent() doesn't work quite like it used to, so I assume that
> this is a known problem / intended functionality. There is mention there
> of buffering issues, so I've tried calling $r->rflush() first but
> $r->bytes_sent() still returns 0. Setting $|=1 on STDOUT also doesn't
> help.

right, if this is all from the response phase then the header filter,
content length filter, includes filter, etc all haven't run yet, so no
bytes have actually been sent.

> 
> Is there any way to get this to work under mod_perl2? If the data is
> indeed buffered somewhere then is there any way to test whether or not
> the buffer is empty?

there probably is using the buckets api.  but again, I'm not sure that
you need to check for the presence of error headers before sending the
error page anymore, since httpd sends headers for you.

HTH

--Geoff

Re: Can't install mod_perl

[Geoffrey Young]

> /usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../x86_64-suse-linux/bin/ld:
> /usr/local/perl_588/lib/CORE/libperl.a(gv.o): relocatio
> n R_X86_64_32S against `a local symbol' can not be used when making a
> shared object; recompile with -fPIC

the first google match for "recompile with -fPIC" and mod_perl gives
what looks to be the answer.

archives++

--Geoff

Re: Configuration Data vs. DirectoryIndex

[Geoffrey Young]

Marc M. Adkins wrote:
> I have been struggling with DirectoryIndex behavior and configuration
> information from custom Perl directives for a while now.  I've been
> scanning the web and posting here and thanks for the previous responses.
> 
> I now have a solution that seems to work.  I have extracted a minimal
> set of tests that demonstrate the problem and my solution, which I have
> attached as an archive (tar czf format).
> 
> I'm not completely happy with my solution, mostly because I'm not
> completely sure why it works -- or perhaps more to the point why it is
> necessary.  I keep thinking that the mod_dir DirectoryIndex should "just
> work" but of course that's bootless.  Either it doesn't in this
> situation or I don't understand something.
> 
> I'd be pleased to have a better solution.  Or an explanation of why
> this one works.  I have tried to reduce the problem to the smallest
> possible footprint to make it easy to review, for them what has the time
> and interest.
> 
> Failing that, perhaps this IS a good solution and may benefit some other
> poor soul.

it's probably just a misunderstanding on your part.  I'll take a look at
it, but I have absolutely no idea what your tarball actually does - that
it contains more than one .conf file is too complex for me to wade through.

try using this as a basis instead:

  http://people.apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz

if you can have 'make test' issue a failure that can be easily verified
I'm pretty sure I can explain what's going on.

see also

  http://marc.info/?l=apache-modperl&m=111335082632706&w=2

specifically

  http://marc.info/?l=apache-modperl&m=111461643218624&w=2

HTH

--Geoff

Re: PerlAuthenHandler PerlAuthzHandler in mod_perl 2.0

[Geoffrey Young]

for the record

> Authen is only called if there is a 'require' 

that's true

> and AuthType/AuthName
> directive,

but that is not :)  you might run into trouble if you don't define those
directives, but their absence won't prevent the auth phases from running.

--Geoff

Re: PerlAuthenHandler PerlAuthzHandler in mod_perl 2.0

[Geoffrey Young]

Martijn wrote:
> Hello.
> 
> I'm doing some testing/debugging on a newly built server (Apache
> 2.0.52, mod_perl 2.0.3) and find that both PerlAuthenHandler and
> PerlAuthzHandler are ignored. 
> 
> 
> # PerlAccessHandler TestHandler
> # the above line *does* block access
> PerlAuthenHandler TestHandler
> PerlAuthzHandler TestHandler
> # same problem if only one of the two lines occurs
> 

you need a Require directive for apache's auth* hooks to run.  see the
introduction to chapter 13 of the mod_perl cookbook here

  http://www.modperlcookbook.org/chapters/ch13.pdf

and the rest of the chapter as well, if you're interested.  the concepts
are the same between httpd 1.3 and 2.0, though the code will require a
bit of modification for mod_perl 2.0.

HTH

--Geoff

Re: mp2 403 intermittent problem

[Geoffrey Young]

> 
> 
> SetHandler  perl-script
> PerlResponseHandler Work::Access::Login
> PerlOptions +ParseHeaders
> ErrorDocument   403 /login
> 

> Additionally, a 500 Internal Server Error error was encountered while
> trying to use an ErrorDocument to handle the request.
> Apache/2.0.53 (Linux/SUSE) Server at internal.blah.com Port 80

this means that the original request returned 403, so apache used an
ErrorDocument to serve up /login.  but /login had some kind of server
error so apache gave up.

long story short, something about Work::Access::Login is triggering a
500 in some circumstances.  your error_log and some verbose tracing
should help  you narrow things down.

--Geoff

Re: PerlChildInitHandler issues

[Geoffrey Young]

Mark Blackman wrote:
> The problem: PerlChildInitHandler handler appears to runs in the parent
> instead of the child.
> 
> After duplicating the code in
> http://perl.apache.org/docs/2.0/user/handlers/server.html
> for MyApache2::Startuplog.pm in the following environment.
> 
> Apache/2.2.4 (Unix) mod_ssl/2.2.4 OpenSSL/0.9.7i mod_perl/2.0.3 Perl/v5.8.8
> 
> The output from the ChildInitHandler suggests that it's being run in the
> parent, ie.
> 
> [Tue Jun 26 11:21:24 2007] - open_logs  : process 8054 is born to reproduce
> [Tue Jun 26 11:21:24 2007] - post_config: configuration is completed
> [Tue Jun 26 11:21:24 2007] - END: process 8054 is shutdown
> 
> [Tue Jun 26 11:21:34 2007] - open_logs  : process 8057 is born to reproduce
> [Tue Jun 26 11:21:34 2007] - post_config: configuration is completed
> [Tue Jun 26 11:21:34 2007] - child_init : process 8057 is born to serve
> [Tue Jun 26 11:21:34 2007] - child_init : process 8057 is born to serve
> [Tue Jun 26 11:21:34 2007] - child_init : process 8057 is born to serve
> [Tue Jun 26 11:21:34 2007] - child_init : process 8057 is born to serve
> [Tue Jun 26 11:21:34 2007] - child_init : process 8057 is born to serve
> 
> I note that this issue appears to have been noted at least once before.
> 
> http://mail-archives.apache.org/mod_mbox/perl-dev/200206.mbox/[EMAIL 
> PROTECTED]
> 
> 
> and fixed of course.
> 
> This looks like a bug to me, but I thought I would confirm with this
> list before reporting
> as such.

I suspect that doug's original fix probably wasn't undone, but that
instead you're running into some iteration of this problem with how perl
itself represents the pid:

  http://marc.info/?t=10663274515&r=1&w=2

so, if you have the ability, you might want to try the same experiment
with a non-threaded perl and prefork mpm and see if you have the same issue.

other than that I really don't know - there were a few different pid
issues floating around, iirc, all having to do with how $$ behaves (as
opposed to what is really going on)

sorry I'm not of more help.

--Geoff

Re: Access apache log variables, eg %h in PerlLogHandler

[Geoffrey Young]

Brad wrote:
> Hi, thanks for the reply Geoff.  I'm actually trying to access the %O
> bytes sent that logio.c places amongst the other variables within the
> logging module.  Thats something that I can't find elsewhere.  Sorry
> about the %h %i example, i thought %O would over complicate the
> question :)

mod_perl generally uses $r->bytes_sent() for this kind of thing

http://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html#C_bytes_sent_

but note the caveat in the docs - it's unlikely bytes_sent() will match
mod_logio's results.  it's a shame mod_logio doesn't set its result in
subprocess_env, which would make accessing it's results a simple matter.

the cool thing, though, is that mod_logio itself has an api, registering
optional functions that you can call.  is, if you _really_ wanted
mod_logio's results you could use some simple xs to create a wrapper and
get at them :)

HTH

--Geoff

Re: mod_perl is already running, too late for PerlSwitches

[Geoffrey Young]

jean jayet wrote:
> Hello all,
> 
> 
> during setup of mod_perl 2 with Apache 2 and perl 5.8.4 on a solaris 10
> 
> make test :
> 
> Syntax error on line 47 of /tmp/mod_perl-2.0.3/t/conf/extra.conf:
> mod_perl is already running, too late for PerlSwitches
> 
> 
> does anybody have an idea what is the pb ?

this error means that the perl interpreter is already resident in the
startup process, so it's too late to tell perl how to start.  so, you
need to trace through httpd.conf and extra.conf for mod_perl-specific
directives.  most of these will be applied as late as possible
(PerlModule, etc) but some will start up the interpreter right away
(, PerlLoadModule) and thus conflict with PerlSwitches.

this is a very rare problem so, if I had to guess, I would think that
the problem rests in your system httpd.conf, which is generated from
scratch but pulls in some of your existing httpd.conf.  if you can't
figure it out from a visual backtrace you may want to

  $ t/TEST -clean
  $ export APACHE_TEST_TRACE_LEVEL=debug
  $ t/TEST -conf

which will spit out a truckload of information about which files the
test configuration is pulling in and from where.

HTH

--Geoff

> 
> rgds,
> Jean
> 
> 
> /tmp/mod_perl-2.0.3/t/conf/extra.conf:
> line 47 : PerlSwitches -wT

Re: Weird response from both CGI and modperl handlers

[Geoffrey Young]

Cyril SCETBON wrote:
> Hi people,
> 
> I've got some problem with both cgi and modperl.
> when I post something to /perl/test.pl which just print header and a
> string I got some strange numbers. The post is done with a php script.
> 
> test.pl :
> 
> use strict;
> use CGI qw/:standard/;
> 
> print header;
> print("\ncoucou\n");
> 
> and below is the response the php script got :
> 
> HTTP/1.1 200 OKDate: Tue, 19 Jun 2007 21:39:55 GMTServer: Apache/2.2.3
> (Ubuntu) mod_ssl/2.2.3 OpenSSL/0.9.8c mod_apreq2-20051231/2.6.0
> mod_perl/2.0.2 Perl/v5.8.8Connection: closeTransfer-Encoding:
> chunkedContent-Type: text/html; charset=ISO-8859-18coucou0
> 
> It got 8coucou0 instead of coucou.
> 

because your php script is not handling the chunked transfer encoding
properly.

  http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1

presumably php has some http-specific libraries for POSTing requests so
that all this low-level stuff becomes stuff you don't need to worry about.

--Geoff

Re: Access apache log variables, eg %h in PerlLogHandler

[Geoffrey Young]

Brad wrote:
> Is there any way I can read variables from apache's log system back into
> a PerlLogHandler?  %h %l etc

you might as well forget about %l - nobody runs with identd.  as for %h
you can use $r->c->get_remote_host()

http://perl.apache.org/docs/2.0/api/Apache2/Connection.html#C_get_remote_host_

mod_log_config merely uses the apache api to spit those bits out to the
log file.  so browse the Apache2::RequestRec, ::ServerRec, ::Conection,
etc and you'll have whatever info you need.

  http://perl.apache.org/docs/2.0/api/

HTH

--Geoff

Re: set auth_type, after subrequest it lost - bug or not ?

[Geoffrey Young]

Sergij Borodych wrote:
> On 06/14/07 16:14, Sergij Borodych wrote:
>> Hi ALL,
>>
>> I need some help
>>
>> I set auth_type (like $r->auth_type('MyType')) in PerlAuthenHandler
>> if request go in "/" (root) it generate subrequest
>> for lookup index.html file name
>> after this in subrequest I lost auth_type (but I ignore subrequests)
>> but even in PerlLogHandler I can't determine it
>>
>> this is bug or not ?
>> becouse in documentation:
>>> auth_type
>>> Get/set the type of authorization required for _this request_
>> I may try workaround with use "pnotes", but I want desirably less as
>> possibly a superfluous code
>>
> 
> As I undestand second(subrequest) call of PerlAuthenHandler
> destroy(remove) my auth_type set(even for main request), so
> I fix it
> 
> set
> $r->auth_type('MyType');
> 
> before
> return OK unless $r->is_initial_req();
> 
> so even in subrequest I set auth_type
> 
> But I have suspicion - is the bug ?
> (I about PerlLogHandler without defined auth_type)
> How do you think ?
> 

if you're using 2.0 then you're probably getting confused at the
difference between $r->auth_type() and $r->ap_auth_type().

$r->auth_type() is the value of the AuthType configuration directive.
it comes from Apache2::Access.

$r->ap_auth_type() is the type of authentication that is actually
performed by the server (you or httpd).  it comes from Apache2::RequestRec.

see

http://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html#C_ap_auth_type_

but, in short, if you're rolling your own authentication mechanism
(which you are) you want to use ap_auth_type() and not auth_type().

HTH

--Geoff

Re: DirectoryIndex vs. PerlTransHandler

[Geoffrey Young]

> My PerlResponseHandler works fine on files in the /tools directory for
> pages that are specified, for example:
> 
> /tools/environment.page
> /tools/index.page
> 
> If I use just the directory URI:
> 
> /tools/
> 
> the DirectoryIndex specification works but I don't get any configuration
> data inside the PerlResponseHandler from any variant of
> Apache2::Module::get_config.  So my response handler doesn't work right.
>   Everything's fine when I specify index.page, and when I don't the URI
> comes back as index.page, but in the case where DirectoryIndex makes
> this happen I don't get any configuration data item.
> 
> I have constructed a PerlTransHandler which can be attached to the
> VirtualHost.  In it I do what DirectoryIndex would do, I check for a
> trailing slash and append index.page.  When I do this the subsequent
> response handler has appropriate configuration data.
> 
> I find this odd.  Can anyone explain why DirectoryIndex doesn't work the
> same as an "equivalent" PerlTransHandler?

please take a look here

  http://marc.info/?l=apache-modperl&m=112805393100758&w=2

--GEoff

Re: Replacement for CGI.pm escape and unescape

[Geoffrey Young]

cfaust-dougot wrote:
> Yes, I'm trying to HTML escape/unescape, although looking at URI::Escape it 
> seems like it might work. I'll have to give it a try.

http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache__Util__escape_html___

http://search.cpan.org/dist/HTML-Parser/

HTH

--Geoff

Re: apache2 does not deny acces though PerlAuthenHandler returns HTTP_UNAUTHORIZED

[Geoffrey Young]

Michael Peters wrote:
> Moritz Maisel wrote:
> 
>>Hi List,
>>
>>I wrote a PerlAuthenHandler to authenticate users that access a
>>webservice. I supposed that by returning either "OK" or
>>"HTTP_UNAUTHORIZED" back to apache2 it will allow or deny acces due to
>>the "require valid-user" directive that I set.
>>My problem is, that apache executes my handler, but it does not take
>>care of my return-values. Instead it always serves the request and
>>grants access.
> 
> 
> The HTTP codes are HTTP return codes, not handler return codes.

actually, that's not really correct...

a handler is expected to return one of

  o apache handler code (OK, DECLINE, DONE)
  o apache _error_ code (SERVER_ERROR, FORBIDDEN, etc)

the confusion is generally when someone assumes OK (0) is the same as
HTTP_OK (200).

so, it's always proper to return an HTTP code in the case of "errors"
where "error" in apache-speak is anything other than 200.

> Use FORBIDDEN instead.

actually HTTP_UNAUTHORIZED (401, aka AUTH_REQUIRED) is more proper than
FORBIDDEN (403) for basic auth, though either should prevent the content
handler from running.

offhand I can't see anything in your code that looks wrong - ordinarily,
of mod_perl authen doesn't do it's job properly you'll see core errors
due to missing AuthUserFile, etc directive that don't really matter if
your custom authen is functional.

if I had to guess I'd say that something else in your httpd.conf is
interfering with your authen setup.  the first thing that comes to mind
is making sure you have 'Satisfy All' and not 'Satisfy Any'

HTH

--Geoff

Re: Apache::DProf missing some subroutines

[Geoffrey Young]

John ORourke wrote:
> Geoffrey Young wrote:
> 
>> Jeff wrote:
>>  
>>
>>> Not sure if its relevant, but from general Perl usage, Devel::Profiler
>>> often fails to properly recognise function names if its USE statement
>>> ends up being executed before your classes have been USEd.
>>> 
>>
>> yes, because Devel::Profiler scans for then during it's import routine.
>>  the behavior is slightly different under mod_perl (the scan is delayed)
>>   
> 
> 
> No joy with Devel::Profiler::Apache sadly - I couldn't even get it to
> write anything out.  I tried log dir permissions, tried creating the
> 'profiler' directory like you have to do for DProf, I even tried
> updating Profiler/Apache.pm to use Apache2::ServerUtil instead of
> Apache->, and I tried pulling it in with either PerlModule or 'use' -
> the only time it even appeared to load was when I tried it with a 'use'
> statement on the original code, and of course it complained about the
> 'Apache' package not existing.

sorry, I didnt' realize this was mp2.  Devel::Profiler in svn has been
ported to mp2 already, so you shouldn't need to worry about that.

as for setup, you can see an exact mod_perl config in the (new) tests
under t/conf in the svn sources.  or you can browse them here

http://devel-profiler.cvs.sourceforge.net/devel-profiler/Devel-Profiler/t/conf/extra.conf.in?revision=1.5
http://devel-profiler.cvs.sourceforge.net/devel-profiler/Devel-Profiler/t/conf/modperl_extra.pl?revision=1.3

in short, you need to

  use Devel::Profiler::Apache;

from your startup.pl, since PerlModule doesn't actually call import().
see the documentation comments in those two files.

fwiw, I'm sorry it's all in svn - I got interested in Devel::Profiler
after version 0.04, and worked hard for a while to improve things on the
mod_perl side, but it's simply been a lack of tuits on everyone's part
getting 0.05 out.

HTH

--Geoff

RFC: Devel::Profiler::Plugins::Template

[Geoffrey Young]

hi all :)

I spent some time this week adding hooks for template toolkit into
Devel::Profiler.  you can find the code here

http://www.modperlcookbook.org/~geoff/modules/experimental/Devel-Profiler-Plugins-Template-0.01.tar.gz

I'm not entirely convinced of the namespace, which is why it's not on
CPAN yet.  but I'd appreciate it if folks could give it a whirl when
they have the chance.

--Geoff

from the docs:

  use Devel::Profiler::Plugins::Template;  # enable TT hooks
  use Devel::Profiler; # required

...

much hackery is involved, so it's not guaranteed
to work on all platforms, versions of perl, or versions of TT.
but if it does work, your C results will look like this

  %Time ExclSec CumulS #Calls sec/call Csec/c  Name
   3.20   0.048  0.048   1794   0. 0.  Encode::_utf8_on
   1.27   0.019  0.028  2   0.0095 0.0140  TT::PROCESS::get_standard_nav
   0.00   0.000  0.000  2   0. 0.
TT::INCLUDE::layout_2fframe_2fhead_2ett

which corresponds to something like

  [% BLOCK get_standard_nav %]
...
  [% END %]

  [% PROCESS get_standard_nav %]
  [% INCLUDE layout/frame/head.tt %]

note that the TT results are right alongside of your normal perl calls,
which I find very convenient.

...

oh, and this probably won't work so well unless you have the current
Devel::Profiler code from svn:

  http://sourceforge.net/projects/devel-profiler/

but it might.

Re: Apache::DProf missing some subroutines

[Geoffrey Young]

Jeff wrote:
>  Original Message 
> Subject: Re:Apache::DProf missing some subroutines
> From: Geoffrey Young <[EMAIL PROTECTED]>
> CC: modperl 
> Date: 11 May 2007 14:11:14
> 
>>
>>> Also, Devel::Profiler can't handle many of the DBI implementations (you
>>> have to bad_pkgs=>[] them.
>>
>>
>> I don't have any trouble with core DBI or DBD::mysql or DBD::Oracle.
>> but there are lots of DBI-esque packages out there so I'll believe you.
>>  in general Devel::Profiler doesn't like overloaded things.
>>
> 
> interesting - DBD::mysql is the one that I reported a problem with a few
> years ago:
> 
> http://groups.google.co.uk/group/perl.perl5.porters/browse_thread/thread/29602d15e7586b79/a11948e8b7854a4b

current svn given me this on our codebase:

 0.67   0.056  0.056780   0.0001 0.0001  DBD::mysql::st::fetch
 0.65   0.054  0.117480   0.0001 0.0002  DBD::_::db::prepare_cached
 0.46   0.038  0.038480   0.0001 0.0001  DBI::db::prepare_cached
 0.44   0.037  0.037480   0.0001 0.0001  DBI::st::execute
 0.34   0.028  0.028480   0.0001 0.0001  DBI::st::bind_columns
 0.23   0.019  0.019220   0.0001 0.0001  DBD::mysql::db::ping
 0.23   0.019  0.019220   0.0001 0.0001  DBI::db::do
 0.23   0.019  0.019480   0. 0.  DBD::mysql::st::execute
 0.22   0.018  0.018220   0.0001 0.0001  DBI::db::ping
 0.22   0.018  0.018700   0. 0.  DBI::db::FETCH
 0.22   0.018  0.018500   0. 0.  DBI::st::FETCH
 0.22   0.018  0.018480   0. 0.  DBD::mysql::st::FETCH
 0.22   0.018  0.018440   0. 0.  DBD::mysql::st::finish
 0.11   0.009  0.009700   0. 0.  DBD::mysql::db::FETCH
 0.11   0.009  0.009480   0. 0.  DBD::_::st::bind_columns
 0.11   0.009  0.009780   0. 0.  DBI::st::fetch
 0.11   0.009  0.009440   0. 0.  DBI::st::finish

which looks reasonable enough to me :)  you might want to give svn a
try.  also, our bad_pkgs looks like

  bad_pkgs => [qw( UNIVERSAL Time::HiRes B Carp
   Exporter Cwd Config CORE DynaLoader XSLoader
   AutoLoader utf8 )],

in case any of those are the ones causing trouble for you.

> 
>> you might also try the latest from svn to see if that works better for
>> you:
>>   http://sourceforge.net/projects/devel-profiler/
> 
> 
> I have the last released => v0.04, June 9 2002, but I see that there was
> a not-yet-released change in 2003 for autoloaded.  Might just wait until
> an 0.05 is floated - we can always blame the database for performance
> issues in the mean time :)

there's no timeframe for 0.05 at this point, but I suspect svn looks
like 0.05 will with the exception of some additional documentation updates.

HTH

--Geoff

Re: Apache::DProf missing some subroutines

[Geoffrey Young]

Jeff wrote:
> 
> Not sure if its relevant, but from general Perl usage, Devel::Profiler
> often fails to properly recognise function names if its USE statement
> ends up being executed before your classes have been USEd.
> 
> If you use factories to instantiate objects from calculated class names,
> those methods won't be recognised unless you explicitly USE them (i.e.
> rather than run-time REQUIRE them).

yes, because Devel::Profiler scans for then during it's import routine.
 the behavior is slightly different under mod_perl (the scan is delayed)
so it probably doesn't have the same effect - in mod_perl we don't want
to generate things the way you're describing since it prevents us from
maximizing shared memory (you want to use() everything before the
children are forked).

> 
> To test if this is your issue, you might find a class with methods not
> being recognised, and add a USE statement for this class just before you
> call in the profiler, and then check the results.

he's not using Devel::Profiler (yet) but maybe Devel::DProf has the same
limitation.  it never hurts to try :)

> 
> Also, Devel::Profiler can't handle many of the DBI implementations (you
> have to bad_pkgs=>[] them.

I don't have any trouble with core DBI or DBD::mysql or DBD::Oracle.
but there are lots of DBI-esque packages out there so I'll believe you.
 in general Devel::Profiler doesn't like overloaded things.

you might also try the latest from svn to see if that works better for you:

  http://sourceforge.net/projects/devel-profiler/

HTH

--Geoff

> 
> Regards
> Jeff
> 
> 
>  Original Message 
> Subject: Apache::DProf missing some subroutines
> From: John ORourke <[EMAIL PROTECTED]>
> To: modperl 
> Date: 11 May 2007 12:36:02
> 
>> Hi folks,
>>
>> Any idea why Apache::DProf would be failing to list some subroutines
>> that are definitely being called, in the tmon.out file?
>>
>> I grepped all sub references from tmon.out and it's listing my method
>> handlers, it's listing some of my constructors, and its listing some
>> object methods, but there are loads missing.  I know they should be
>> there because some of the listed subs are only called from non-listed
>> ones!
>>
>> The only things I'm doing which might affect it are:
>>  - a fair bit of subclassing, but that doesn't explain many of the
>> missing ones
>>  - using Error.pm - could this be interfering?
>>
>> cheers
>> John
>>

Re: Apache::DProf missing some subroutines

[Geoffrey Young]

John ORourke wrote:
> Hi folks,
> 
> Any idea why Apache::DProf would be failing to list some subroutines
> that are definitely being called, in the tmon.out file?
> 
> I grepped all sub references from tmon.out and it's listing my method
> handlers, it's listing some of my constructors, and its listing some
> object methods, but there are loads missing.  I know they should be
> there because some of the listed subs are only called from non-listed ones!
> 
> The only things I'm doing which might affect it are:
>  - a fair bit of subclassing, but that doesn't explain many of the
> missing ones
>  - using Error.pm - could this be interfering?

I have no idea, but I'd suggest trying Devel::Profiler, as it tends to
handle mod_perl applications more gracefully.  it also has an interface
for skipping over unfriendly packages and subs, which Error.pm may
indeed be.

it also will shortly have a TT plugin for adding [% PROCESS %] timings
to tmon.out, if you find that kind of thing useful ;)

--Geff

[Fwd: Registration Is Open for OSCON 2007]

[Geoffrey Young]

fyi

 Original Message 
Subject: Registration Is Open for OSCON 2007
Date: Mon, 30 Apr 2007 14:43:24 -0700
From: O'Reilly Open Source Convention <[EMAIL PROTECTED]>
To: GeoffreyYoung <[EMAIL PROTECTED]>

O'Reilly Open Source Convention
July 23-27, 2007 in Portland, OR
http://conferences.oreilly.com/oscon

Reserve your place now for OSCON 2007, happening July 23-27 in Portland,
Oregon. Save $200 when you register by June 4!

Join more than 2500 open source developers, gurus, experts, and users at
the ninth annual O'Reilly Open Source Convention--five days of
wall-to-wall sessions, tutorials, and events, plus the O'Reilly Radar
Executive Briefing.

Register now at http://conferences.oreillynet.com/pub/w/58/register.html.
You'll find complete information on available discounts and attendance
packages. You may also sign up separately for tutorials or for the
O'Reilly Radar Executive Briefing.

More than 400 Sessions in 15 Tracks (Wednesday-Friday)
Sessions focusing on proven successes and newly-developed technology are
organized in tracks for Administration, Business Databases, Java, Linux,
People, Perl, PHP, Programming, Python, Ruby, Security, and Web
Applications. Sponsors will also be showcasing their latest wares in the
Products & Services track.

Speakers and topics are still being confirmed, but here's a sampling of
what you'll hear from whom:
-"Advanced Effects in Desktop Java Applications," Kirill Grouchnikov, Amdocs
-"PHP: Bigger and Faster," Rasmus Lerdorf, Yahoo!
-"High Availability Xen," Lamont Peterson, NeverBlock
-"OpenID Bootcamp," Simon Willison
-"Exploiting Multi-Core Capabilies From Python," Rachael Madsen
-"Python 3000," Guido van Rossum, Google
-"Advanced Production Troubleshooting," Theo Schlossnagle, OmniTI
-"A Year of Open Source at Google," Chris DiBona, Google
-"A Taste of Haskell," Simon Peyton Jones, Microsoft
-"Generating Gorgeous Word Documents, PDFs, and Excel Spreadsheets,"
Michael Koziarski
-"Building Domain Specific Languages in Perl," Jesse Vincent, Best
Practical
-"DBA Tales from the Front: from Oracle to MySQL," Ben Krug, Adapt
Technologies
-"Art of Community," Dawn Foster and Danese Cooper, Intel
-"Hello? Is There a User in the House?" Amy Hoy, LimeWire
-"Why User Space Sucks," Dave Jones, Red Hat
-"Open Source Voting," Arthur Keller, Open Voting Consortium
-"DBA Tales from the Front: From Oracle to MySQL," Ben Krug, Adapt
Technologies
-"Open Source Data...It's Changing Your Life," Stormy Peters, Open Logic

Other featured speakers include Robert Lefkowitz of Asurion, Rasmus
Lerdorf of Yahoo!, Howard Lewis Ship from Tapestry World Domination, Vik
Olliver of RepRap, Microsoft's Simon Peyton-Jones, Canonical founder Mark
Shuttleworth, Perl creator Larry Wall, Simon Willison, and many more
heros of open source. See the full list of speakers so far at:
http://conferences.oreillynet.com/pub/w/58/speakers.html

Two Full Days of Tutorials (Monday and Tuesday)
These three-hour presentations provide a forum for collaborative learning
and exploratory participation, as well as a first-hand opportunity to
master the power of open source software. See the complete schedule of
tutorials at http://conferences.oreillynet.com/pub/w/58/tutorials.html

O'Reilly Radar Executive Briefing (Tuesday)
Led by Tim O'Reilly and the Radar team, this all-day event focuses on the
business of open source software and related technologies from the
viewpoint of the industry innovators and entrepreneurs who are changing
our thinking right now. Intimate by design, the Executive Briefing is
more about conversation than formal presentation, giving you the chance to
meet these passionate, smart, wildly innovative people, who will share their
ideas and experiences. You'll come away from the day inspired, energized
and ready to apply what you've absorbed to your own business.

Experts, visionaries, open source professionals, sys admins, developers,
and hackers in the trenches will meet and mingle in OSCON's hallways,
Expo Hall (filled with sponsors like Autodesk, Novell, Google, Intel,
New York
Times, Sun, Microsoft, Optaros, IBM, and Ingres), and fun evening events.

As Matt Asay of Infoworld remarked at last year's conference, there's "no
better place on this earth to find out how to use all the cool new open
source projects, and to see what's coming next."

Sign up for the OSCON newsletter for updates on speakers, sessions and
events (login required):
http://www.oreillynet.com/cs/nl/home#conferences

We hope to see you in Portland in July!

The OSCON Team

P.S. Register by June 4 and save $200÷-or more! For complete information
on discounts and registration options, go to:
http://confere

Re: Apache::TestMB ignores '-axps=' flag ?

[Geoffrey Young]

Joshua Hoblitt wrote:
> Hi Folks,
> 
> I just discovered that version of Apache::TestMB (no version string)
> from Apache-Test 1.29 is ignoring the -apxs= flags passed on the command
> line. E.g., `perl Build.PL -axps=/usr/sbin/apxs2`. 

I really don't know the M::B extension to A-T, but in Makefile-land
there is no equal sign.  that is, it's

  perl Makefile.PL -apxs /usr/sbin/apxs2

and not

  perl Makefile.PL -apxs=/usr/sbin/apxs2

so, try that.  yeah, I know, it's silly and inconsistent, but... :)

--Geoff

Re: $r->handler and $r->set_handlers on all files

[Geoffrey Young]

>>> 
>>> PerlAuthzHandler MyModule::authorize
>>>
>>> and in authorize:
>>>
>>> if ...
>>> $r->handler('perl-script');
>>> $r->set_handlers( (MP2 ? 'PerlResponseHandler' : 'PerlHandler') =>
>>> \&somefunc );
>>
>>
>> why are you doing this?  those same directives in httpd.conf are a
>> cleaner way to go - if your PerlAuthzHandler returns FORBIDDEN they will
>> never be executed.
> 
> 
> I know, but I need show custom html page (with custom error message)

you can pass anything you like from your authz handler to your content
handler using $r->pnotes :)

--Geoff

Re: $r->handler and $r->set_handlers on all files

[Geoffrey Young]

Sergij Borodych wrote:
> Hi,
> 
> I have configuration:
> apache-2.0.59
> mod_perl-2.0.3
> 
> 
> PerlAuthzHandler MyModule::authorize
> 
> and in authorize:
> 
> if ...
> $r->handler('perl-script');
> $r->set_handlers( (MP2 ? 'PerlResponseHandler' : 'PerlHandler') =>
> \&somefunc );

why are you doing this?  those same directives in httpd.conf are a
cleaner way to go - if your PerlAuthzHandler returns FORBIDDEN they will
never be executed.

--Geoff

Re: [Fwd: Call for Papers Opens for ApacheCon US 2007]

[Geoffrey Young]

Issac Goldstand wrote:
> ISn't that kind of short notice?  Even for a proposal and certainly for
> the paper...

it is what it is, and I suspect that the deadline is meant to be just
before the conference committee meets for ApacheCon EU the following week.

as for the distinction between "proposal" and "paper" you imply, there
really isn't one - this should really be "call for proposals" as all
that's required is a short description of your suggested conference
session or tutorial (as opposed to a full academic paper or somesuch).

--Geoff

Re: [Fwd: Call for Papers Opens for ApacheCon US 2007]

[Geoffrey Young]

> The paper submission deadline is Monday, 28 April 2007, Midnight GMT.

note that the date (april 28) is correct, but it's a saturday not a monday.

--Geoff

Re: Can't locate ModPerl/Registry.pm in @INC

[Geoffrey Young]

Perrin Harkins wrote:
> On 4/11/07, michael watson (IAH-C) <[EMAIL PROTECTED]> wrote:
> 
>> Well, when I used the "static install" instructions (on an identical
>> server) ModPerl/Registry.pm was installed in a suitable place.
>> When I followed the "Dynamic install" instriuctions, it got stuck
>> under /usr/local/apache2/.
> 
> 
> Wait, maybe I've got this wrong.  I never do dynamic installs.

I do them all the time and I've never had modules install themselves
anyplace other than perl's @INC.

michael: I'd nuke /usr/local/apache2 and try again.  if you still run
into trouble, please follow the steps here

  http://perl.apache.org/bugs/

specifically running t/REPORT as it will send back all the args passed
to Makefile.PL, perl's @INC, etc.

thanks.

--Geoff

Re: Can't locate object method "is_threaded" via package "Apache2::MPM"

[Geoffrey Young]

michael watson (IAH-C) wrote:
> I'm running Apache/2.2.4 (Unix) mod_perl/2.0.3 Perl/v5.8.0 configured.
> 
> BEGIN in Apache2::SizeLimit has the code:
> 
> die "Apache2::SizeLimit at the moment works only with non-threaded
> MPMs"
> if Apache2::MPM->is_threaded();

nothing wrong with that.

> 
> Yet if I run:
> 
> %> perl
> use Apache2::MPM;
> print Apache2::MPM->is_threaded();
> 
> I get:
> 
> Can't locate object method "is_threaded" via package "Apache2::MPM" at -
> line 2.

of course - you can't really do much with Apache2:: modules outside of a
running mod_perl environment.  in this case Apache2::MPM::is_threaded()
is an constant subroutine created at runtime when mod_perl can query the
running Apache server and figure out whether it is using some threaded
mpm or not.

> 
> The site I am trying to install relies on a modperl startup script, and
> it is failing because it cannot find the is_threaded method in
> Apache2:MPM.

hopefully, you're typing Apache2::MPM with two colons ;)

> 
> What am I missing?

if you have the mp2 sources and build available you can see Apache2::MPM
exercised by doing this:

  $ t/TEST t/api/query.t -v

the source for which is here

  t/response/TestAPI/query.pm

short of that, you might want to perldoc the Apache2::MPM manpage and
try calling show() in your startup script (in addition to is_threaded())
and see what happens.

--Geoff

Re: Client certificate based authentication

[Geoffrey Young]

Jonathan Vanasco wrote:
> 
> On Apr 8, 2007, at 6:29 AM, Erik Norgaard wrote:
> 
>> First, this might me a stupid question, but I haven't found (or 
>> understood) how this works. When you have multiple handlers each 
>> being called in different stages of the request handling, how do  you
>> pass information from one handler to the next?
>> I am thinking of a separate authentication handler (not  authorization
>> as that depends on the action the user wants to do),  how to I pass on
>> authentication details to the response handler?
> 
> 
> pnotes
> http://perl.apache.org/docs/2.0/api/Apache2/RequestUtil.html#C_pnotes_

while pnotes is a gem, keep in mind that there are official channels for
communication of user data when rolling your own authentication
mechanism - authentication handlers are expected to set $r->user() and
$r->connection->auth_type().

furthermore, I know from experience that some folks have a difficult
time understanding the phase separation, so I'll just say it for
clarity's sake... you don't need to pass some special flag to the
response handler saying "this user has been authenticated" or anything
like that - if the user fails authentication they won't ever make it to
your response handler.

this might help you a bit:

  http://www.modperlcookbook.org/chapters/ch13.pdf

especially the final two recipes, which involve rolling your own auth
mechanism.

HTH

--Geoff

Re: [RELEASE CANDIDATE] Apache-SizeLimit 0.91 RC4

[Geoffrey Young]

Philippe M. Chiasson wrote:
> This release should be the final RC, the same as what would ship
> in the latest mod_perl 1.30 RC2.
> 
> http://people.apache.org/~gozer/mp1/Apache-SizeLimit-0.91-rc4.tar.gz

looks good (finally :)

+1

--Geoff

Re: MP1 Security issue

[Geoffrey Young]

Randal L. Schwartz wrote:
>>"Jonathan" == Jonathan Vanasco <[EMAIL PROTECTED]> writes:
> 
> 
> Jonathan> Randal didn't raise an report an new security threat --  he re-
> Jonathan> categorized an active bug discussion as a security threat.
> 
> Just for the record, I'm now clear (thanks to new information) that I handled
> this poorly, and will handle it differently the next time.  

in all fairness, I do appreciate you paying attention and speaking up.
if the security implications had not been brought up there's always the
possibility that Evil Guy would have seen the exploit, that the
developers wouldn't have patched things fast enough, and that much chaos
would have been the result.

I just wish we hadn't given the bad guys such a clear roadmap to the
chaos :)

> I apologize for
> any stress or grief, or even break-in, that may have resulted from my actions.

thankfully, I don't think the risk is as great as anybody thought at
first.  but just to put things in perspective, the top two mod_perl
shops transact _billions_ of dollars through mod_perl servers, so a more
serious security threat... well, I think that could have had an
incredible impact on all of us who work in open source, not just our
little corner of it.

> 
> Jonathan> People have commented "This isn't the proper way to report a
> Jonathan> security threat."  Well, right now ModPerl doesn't have a published
> Jonathan> protocol for dealing with security threats.
> 
> I *do* strongly support this statement though.  Even after having been LARTed,
> googling for "security mod_perl" didn't reveal anything in the first ten hits
> that would be remotely useful here.
> 
> This *can* be fixed for the future.  (Nudge to the developers.)

I had actually started patching the documentation before jonathan said
anything, so expect something soonish.  still, short of an official
channel to report security issues, it's always probably safe to say
"hey, I think this poses a security issue.  what's the best way to
handle things?" no matter which mailing list you're on :)

--Geoff

Re: Apache2::compat from mod_perl 2.0.3 -- multiple issues

[Geoffrey Young]

Joshua Hoblitt wrote:
> It seems that compat.pm isn't 'use strict' clean even thou it is
> declaring this pragma.
> 
> # Error:  Bareword "Apache2::ServerUtil::server_root" not allowed
> while "strict subs" in use at
> /usr/lib/perl5/site_perl/5.8.8/i686-linux/Apache2/compat.pm line 347,
>  line 9.
> 
> This error is caused by 'Apache2::ServerUtil::server_root' (note that
>  missing '()') and this repeated in several places through-out
> compat.pm.

you are not the first to report this, but I guess we've let it slip
until now.  fixed in svn.  thanks.

> 
> Commenting out the 'use strict' at the top of compat.om reveals
> another more serious error:
> 
> # Error:  Undefined subroutine
> &Apache2::ServerUtil::restart_count called at
> /usr/lib/perl5/site_perl/5.8.8/i686-linux/Apache2/compat.pm line 76,
>  line 9.
> 
> Which I assume is supposed to be provided by ServerUtil.so except
> that this symbol isn't defined in this lib.
> 
> nm ./Apache2/ServerUtil/ServerUtil.so | grep restart 1cf0 T
> XS_Apache2__ServerUtil_restart_count U modperl_restart_count
> 
> Any ideas as to what might have gone wrong in the build?

that's strange.  did all tests pass for you?  we explicitly exercise
this in several of the test scripts.

keep in mind that lots of this stuff won't work if you just do something
like

  $ perl -cw lib/Apache2/compat.pm

you really need to call it from within a live, running mod_perl
environment.  if you are, please consider sending along a minimal test
case that reproduces the issue.  see http://perl.apache.org/bugs/

--Geoff

Re: [RELEASE CANDIDATE] mod_perl-1.30 RC1

[Geoffrey Young]

Philip M. Gollucci wrote:
> Philippe M. Chiasson wrote:
> 
>> The mod_perl 1.30 release candidate #1 has arrived. It can be
>> downloaded here:
>>
>> http://www.apache.org/~gozer/mp1/mod_perl-1.30-rc1.tar.gz
>>
>> MD5 : 639e045d782a66746a70b7948dfa
>> SHA1: 942eaffe4570a9060b3a0ed7de52ac902d054cbb
> 
> 
>> Pull in the new Apache-SizeLimit from
>> http://svn.apache.org/repos/asf/perl/Apache-SizeLimit/trunk
>> and obsolete the previous lib/Apache/SizeLimit.pm.
>> [Philip M. Gollucci]
> 
> So this is currently an UnReleased version of Apache-SizeLimit.
> Is everyone okay with its current state and that its unreleased ?

we should probably either:

  o follow the Apache-Test lead and release a separate Apache-SizeLimit
distribution to CPAN for each mp1 and/or mp2 release

or

  o yank the svn link and replace with static files representing the
current state of things on CPAN

I feel like you've done most of the work on A-SL, so you're in the best
position to judge which path we should take, based on the state of
current svn code.  meaning, if you deem it stable then I think we're
fine, but if it's in the middle of some grand migration experiment you
haven't had time to finish then we probably ought to back it out.

if we weren't in need of a security release asap then we'd probably have
time to make it right.  but I think we need to make a decision based on
what we have in svn now with very minimal changes (or rollback to CPAN)

make sense?

--Geoff

Re: [RELEASE CANDIDATE] mod_perl-1.30 RC1

[Geoffrey Young]

Randal L. Schwartz wrote:
>>"Philippe" == Philippe M Chiasson <[EMAIL PROTECTED]> writes:
> 
> 
> Philippe> SECURITY: CVE-2007-1349 (cve.mitre.org)
> 
> Is it disinformation at
>  that says it was
> assigned on march *8th*.  Last I looked, it was closer to the 23rd.  Weird.
> 
> Or is the number copied wrong?

I've been told both are correct - the numbers are allocated in advance
to the ASF contact person, who then assigns them to projects as necessary.

--Geoff

Re: MP1 Security issue

[Geoffrey Young]

> Michael> Not quite. It only affects people running PerlRun. Not insignificant,
> Michael> but definitely not everyone.
> 
> No, it affects users of all script-like things, both mod_perl1 (users of
> Apache::Registry, Apache::PerlRun), and mod_perl2 (users of ModPerl::PerlRun,
> ModPerl::PerlRunPrefork, ModPerl::Registry, ModPerl::RegistryBB,
> ModPerl::RegistryPrefork).  They've all copied the same common code.

this is fud.  please stop.  please read my recent emails, or take the
time to examine the code in detail.

--Geoff

Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols)

[Geoffrey Young]

> I was able to reproduce this in mp1.
> 
> for the interested, a fix has been put in place in svn for mod_perl 1.0,
> which you can grab from here:
> 
>   https://svn.apache.org/repos/asf/perl/modperl/branches/1.x/
> 
> furthermore, as michael pointed out, the problem is isolated to
> Apache::PerlRun - Apache::Registry has had a similar fix in it since
> mid-2000 and Apache::RegistryNG is filename based, not url based.

as for mp2, nothing in the current distribution is affected -
ModPerl::Registry and ModPerl::PerlRun are both filesystem based and not
uri based.  however, if you use RegistryCooker to roll your own
non-standard Registry handler and are using the non-standard uri-based
methods then you will want to examine your code.

--Geoff

Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols)

[Geoffrey Young]

Kjetil Kjernsmo wrote:
> On Friday 23 March 2007 14:57, Geoffrey Young wrote:
> 
>>fwiw, I am unable to reproduce this in either mp1 or mp2 using what I
>>consider a basic setup.
> 
> 
> I have also failed to reproduce the problem on 2.0.3 with my setup. 
> Also, we are very liberal on what kind of usernames, and thus what 
> special characters can enter the URI, and in some cases they go through 
> a registry script, and we have not observed any crashes due to this. 

I was able to reproduce this in mp1.

for the interested, a fix has been put in place in svn for mod_perl 1.0,
which you can grab from here:

  https://svn.apache.org/repos/asf/perl/modperl/branches/1.x/

furthermore, as michael pointed out, the problem is isolated to
Apache::PerlRun - Apache::Registry has had a similar fix in it since
mid-2000 and Apache::RegistryNG is filename based, not url based.

--Geoff

Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols)

[Geoffrey Young]

Michael Peters wrote:
> Randal L. Schwartz wrote:
> 
>>>"Alex" == Alex Solovey <[EMAIL PROTECTED]> writes:
>>
>>Alex> The problem is due to unescaped variable interpolation in regular
>>Alex> expression $uri =~ /$path_info$/ in sub namespace_from:
>>
>>I don't want to raise too many alarms, but this means that every MP1 server
>>has a denial-of-service attack against it now.
> 
> 
> Not quite. It only affects people running PerlRun. Not insignificant, but
> definitely not everyone.

fwiw, I am unable to reproduce this in either mp1 or mp2 using what I
consider a basic setup.

this does not mean that I don't agree with the assessments thus far.
but one thing it does mean, though, is that we can't be sure we have a
fix in place if we are unable to verify before and after scenarios.

so, I could use some help here.  if anyone is able to reproduce it
please email me PRIVATELY with

  o relevant httpd.conf
  o sample script

again, watch your reply-all button - no need to expose things to the
world and forever in google at the moment :)

alternatively, anyone with an interest can join #mp-security on
irc.pobox.com (irc.perl.org) so we can get this resolved quickly.

--Geoff

Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols)

[Geoffrey Young]

Randal L. Schwartz wrote:
>>"Randal" == Randal L Schwartz  writes:
> 
> 
>>"Alex" == Alex Solovey <[EMAIL PROTECTED]> writes:
> 
> Alex> The problem is due to unescaped variable interpolation in regular
> Alex> expression $uri =~ /$path_info$/ in sub namespace_from:
> 
> Randal> I don't want to raise too many alarms, but this means that every MP1
> Randal> server has a denial-of-service attack against it now.
> 
> And MP2 as well, from ModPerl::RegistryCooker:
> 
> my $path_info = $self->{REQ}->path_info;
> my $script_name = $path_info && $self->{URI} =~ /$path_info$/
> ? substr($self->{URI}, 0, length($self->{URI}) - length($path_info))
> : $self->{URI};
> 
> Wonderful.  Won't take long until this makes the rounds.  Better start
> getting the patches out and the press releases.

this sensationalism was just flat-out irresponsible.  I don't doubt that
it's true, but not giving us dev folks time to address the issue with a
security release is going to cause more headaches than it otherwise
would have.

in the future, if anyone has a security issue with any apache product,
the proper path to follow is to send a brief email to
[EMAIL PROTECTED]  those guys will make sure it gets routed to the
appropriate place (the mod_perl pmc and core development team in this
case) and we'll work with you to get it clarified and resolved.

--Geoff

Re: Zend PHP

[Geoffrey Young]

> To be fair to Zend... you should checkout their
> products, as it's not just about the support, but the
> fact that they have a whole integrated developer
> studio and deployment mechanism... And many other
> whistles and Bells...

I'm sure that's true.  if that's appealing to you and you'd like to
stick with perl activestate has a solution that's probably a very
parallel offering:

  http://activestate.com/solutions/perl/

--Geoff

Re: Accessing SSL environment variables?

[Geoffrey Young]

Hadmut Danisch wrote:
> Hi,
> 
> another problem with porting an older authentication script:
> 
> The script used to fetch the certificate details set from the SSL module 
> under Apache1.3 with some code like
> 
>   $r->subprocess_env;   # initialize
>   $envs   = $r->subprocess_env;
>   $dn = $r->subprocess_env('SSL_CLIENT_DN');
>   $cn = $r->subprocess_env('SSL_CLIENT_CN');
> 
> 
> it worked. 
> 
> Now, under Apache2.2, I can access only a few variables like HTTP_... or
> SERVER_... variables, but not the varialbes set from the SSL module. 
> 
> (The SSL option StdEnvVars is set, the variables can be seen from PHP
> programs.)

see

  http://search.cpan.org/dist/Apache-SSLLookup/

HTH

--Geoff

Re: MP 2.0.3 & Apache 2.2.3 -> auth tests fail

[Geoffrey Young]

> Or just have a look at this patch ;-)

wicked cool!


> -ok t_cmp(Apache2::ServerUtil::get_server_version,
> +ok t_cmp(Apache2::ServerUtil::get_server_description,

all the tests will need some sort of get_min_apache_version() foo
wrapping, no?

other than that, excellent.  gozer++

--Geoff

Re: [RELEASE CANDIDATE] Apache-SizeLimit 0.91 RC1

[Geoffrey Young]

Philip M. Gollucci wrote:
> Fred Moyer wrote:
> 
>>Philip M. Gollucci wrote:
>>
>>>Fred Moyer wrote:
>>>
Philip M. Gollucci wrote:
> 
> Hi All, so it seems I dropped the ball on this (again).  My apologies.
> 
> I'm about to go dig through all 1000 emails to dev and users to see what
> I missed, but I think its time for an -RC2.
> 
> Afterwards, we can move on incorporating it into mod_perl{1,2] and
> releasing them.
> 
> Then we can move on catching up to 2.2.x+
> 
> Any objections ?

+1

> 
> P.S.
>   I'm actually going to get some time from Ticketmaster for A-SL as we
> need a bug fix in the .9 series.

:)

--Geoff

Re: DateTime with Apache::SmallProf

[Geoffrey Young]

Raf wrote:
> On Wed, 24 Jan 2007, Perrin Harkins wrote:
> 
>>On 1/24/07, Raf <[EMAIL PROTECTED]> wrote:
>>
>>>The code base I'm profiling is very big, monolithic and convoluted.  I
>>>felt that level of granularity given by smallprof would probably give me
>>>more coverage - which I believe I need.
>>
>>Usually that's the reason you use DProf -- it gives you the big
>>picture.  SmallProf is only useful when you've got it down to one sub
>>and you can't figure out which lines in the sub are taking the time.
> 
> 
> Since you put it like that, I stand corrected and don't know what I had
> been thinking. :)  DProf does not seem to be causing DateTime to die, and
> I suppose that while resolving my problem, it still leaves the original
> question open as an X-File.

I'm not a big profiling expert, but I've heard rumors around work that
we could never get Apache::DProf to really work (due to some magic in
own own code), but that the apache hooks in Devel::Profiler worked much
better.  ymmv.

--Geoff