Re: Test Failures on CentOS 7.3

[David E. Wheeler]

On Mar 17, 2017, at 4:13 PM, Jie Gao  wrote:

> You can build and install your own perl, mod_perl, Apache in /usr/local, 
> entirely separate from those that come with the OS.

Yeah, we’re using the system Apache.
‘
D



smime.p7s
Description: S/MIME cryptographic signature

Re: Test Failures on CentOS 7.3

[David E. Wheeler]

On Mar 17, 2017, at 2:33 PM, Jie Gao  wrote:

> Please check if there is a package for apreq you need to install first.

Turns out the problem was that it was installed, but for another Perl. Whole 
problem is that one can’t have multiple Perl builds with mod_perl or libapreq2 
since they all have to put files in the same place (the .so files). Turns out I 
don’t need mod_perl for this build; I got it working for another. So I’ll just 
have to use a new VM to do this one if we ever do need it.

Thanks,

David

smime.p7s
Description: S/MIME cryptographic signature

Re: Test Failures on CentOS 7.3

[David E. Wheeler]

On Mar 17, 2017, at 12:08 PM, David E. Wheeler <da...@justatheory.com> wrote:

> Is there some reason why httpd_info would not be properly set up?

Neglected to mention that I get a lot of these warnings:

httpd: Syntax error on line 353 of /etc/httpd/conf/httpd.conf: Syntax error on 
line 4 of /etc/httpd/conf.d/apreq.conf: Cannot load modules/mod_apreq2.so into 
server: /etc/httpd/modules/mod_apreq2.so: cannot open shared object file: No 
such file or directory

I managed to get all my tests passing by commenting out this line in the system 
httpd.conf:

IncludeOptional conf.d/*.conf

Then all my tests passed. It didn’t like apreq or cgi. Guess this configuration 
is a bit screwed up; got some cleanup to do.

Thanks,

David



smime.p7s
Description: S/MIME cryptographic signature

Test Failures on CentOS 7.3

[David E. Wheeler]

Fellow mod_perlers,

Hey, just noticed that 2.0.10 is out. Nice! Unfortunately I’m getting test 
failures on CentOS 7.3:

Test Summary Report
---
t/api/module.t(Wstat: 0 Tests: 14 Failed: 1)
  Failed test:  14
  Parse errors: Bad plan.  You planned 487 tests but ran 14.
t/api/server_const.t  (Wstat: 0 Tests: 2 Failed: 1)
  Failed test:  2
  Parse errors: Bad plan.  You planned 6 tests but ran 2.


Trolling through the error log, I see these errors:

Use of uninitialized value $mmn_minor in numeric le (<=) at 
t/response/TestAPI/module.pm line 89.
Use of uninitialized value $version in quotemeta at 
t/response/TestAPI/server_const.pm line 41.

$mmn_minor is set from:

my $mmn_minor = $cfg->{httpd_info}{MODULE_MAGIC_NUMBER_MINOR};

$version is set from:

my $version = $cfg->{httpd_info}->{VERSION};


Is there some reason why httpd_info would not be properly set up?

Thanks,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: [RELEASE CANDIDATE]: mod_perl-2.0.9 RC3

[David E. Wheeler]

On Jun 10, 2015, at 10:13 AM, Steve Hay steve.m@googlemail.com wrote:

 Note that Perl 5.22.x is currently not supported. This is logged as
 CPAN RT#101962 and will hopefully be addressed in 2.0.10. [Steve Hay]

Oh, bummer. I was just looking at this, as it’s core-dumping. Is it difficult 
to fix? Is 2.0.10 likely to come sooner than 2.0.9 did?

Thanks,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: [RELEASE CANDIDATE]: mod_perl-2.0.9 RC1

[David E. Wheeler]

On May 13, 2015, at 3:52 PM, David E. Wheeler da...@justatheory.com wrote:

 Tested builds on CentOS 6 and 7, with the system Perl and a custom 5.20 
 build. Both build nicely, with just a simple patch for the system Perl 
 wanting a header with “CentOS” in it instead of “Unix”. Yay!

Having difficulting testing against my Perlbrew-installed 5.22.0 and Apache 
2.2.27 on OS X:

waiting 120 seconds for server to start: .[Tue Jun 02 10:20:16 2015] [warn] 
module apreq_module is already loaded, skipping
httpd: Syntax error on line 70 of 
/Users/david/Desktop/mod_perl-2.0.9-rc1/t/conf/httpd.conf: Cannot load 
/Users/david/Desktop/mod_perl-2.0.9-rc1/src/modules/perl/mod_perl.so into 
server: 
dlopen(/Users/david/Desktop/mod_perl-2.0.9-rc1/src/modules/perl/mod_perl.so, 
10): Symbol not found: _modperl_handler_name
  Referenced from: 
/Users/david/Desktop/mod_perl-2.0.9-rc1/src/modules/perl/mod_perl.so
  Expected in: dynamic lookup

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: [RELEASE CANDIDATE]: mod_perl-2.0.9 RC1

[David E. Wheeler]

On May 13, 2015, at 1:40 PM, Steve Hay steve.m@googlemail.com wrote:

 http://people.apache.org/~stevehay/mod_perl-2.0.9-rc1.tar.gz
 
 
 If I can vote for my own RC then it's a +1 from me :-)

Tested builds on CentOS 6 and 7, with the system Perl and a custom 5.20 build. 
Both build nicely, with just a simple patch for the system Perl wanting a 
header with “CentOS” in it instead of “Unix”. Yay!

  https://github.com/iovation/rpmcpan/blob/master/SOURCES/mod_perl-centos.patch

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: 2.0.9?

[David E. Wheeler]

On May 2, 2015, at 4:07 PM, Steve Hay steve.m@googlemail.com wrote:

 We've just released a new Apache-Test and currently have an RC for 
 Apache-Reload awaiting more test results, and then I intend to roll an RC1 
 for 2.0.9, so it should indeed be fairly soon now.

Great, thank you.

 Thanks for the patch. I've have a closer look later and will certainly bear 
 it in mind if problems are reported in that area.

I updated my builds to use a subversion checkout and haven’t needed the patch. 
shrug.

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

2.0.9?

[David E. Wheeler]

mod_perlers,

What are the chances of a 2.0.9 release soon(ish)? I notice that the CentOS 7 
EPEL RPM is built from Subversion; would be nice to have a formal release with 
fixes from the last 18 months.

  http://dl.fedoraproject.org/pub/epel/7/SRPMS/repoview/mod_perl.html

BTW, that RPM also includes a single patch. Not sure if this would be useful 
applied to main or if it’s specific to CentOS:

--- mod_perl-2.0.4/src/modules/perl/modperl_common_util.h.inline
+++ mod_perl-2.0.4/src/modules/perl/modperl_common_util.h
@@ -22,7 +22,7 @@
 #ifdef MP_DEBUG
 #define MP_INLINE
 #else
-#define MP_INLINE APR_INLINE
+#define MP_INLINE
 #endif
 
 #ifdef CYGWIN

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: How Do I change the Document Root Per Request

[David E. Wheeler]

On Mar 6, 2015, at 5:29 PM, David E. Wheeler da...@justatheory.com wrote:

 And now it works just how I want.

I take it back. It works for files in the root, but not subdirectories.

So say my document root is /var/html, and a request comes in for /foo/bar.html. 
Apache has mapped it to /var/html/foo/bar.html, but in my PerlTypeHandler, I 
re-map it to /var/html/david/foo/bar.html and set finfo:

  sub handler {
  my $r = shift;

  # We only want to do this once per request.
  return DECLINED unless $r-is_initial_req;

  # Get the username.
  my $user = $r-user or return HTTP_UNAUTHORIZED;

  # Return forbidden if the subscriber ID subdirectory does not exist.
  my $doc_root = $r-document_root;
  my $sub_root = File::Spec-catdir($doc_root, $user);
  return HTTP_FORBIDDEN unless -d $sub_root;

  # Set the filename.   
   
  my $file = File::Spec-catfile($sub_root, substr $r-uri, 1);
  $r-filename($file);
  $r-finfo(APR::Finfo::stat($file, APR::Const::FINFO_NORM, $r-pool));
  return DECLINED;
 }

I have no PerlReponseHandler, so Apache handles the response…and returns 404. 
Note that a request for /hi.txt; it’s only a request in a subdirectory, 
/foo/bar.html, that fails. Why? Why isn’t Apache able to find that file? Is 
there some other attribute of $r I need to set or unset?

Thanks,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: How Do I change the Document Root Per Request

[David E. Wheeler]

On Mar 11, 2015, at 10:39 AM, Lathan Bidwell lat...@andrews.edu wrote:

 That is very curious. What was in path_info before? Is this a difference 
 between undef and ? Because path_info shouldn't be involved in finding the 
 file, unless Apache is configured to ignore path info. And even that doesn't 
 make sense because you weren't testing with /foo/bar.html/extra/pathinfo

If I requested /foo/bar/hi.html, filename would be /foo/bar and path_info would 
be /hi.html. It might be that Apache decided to do something funky here because 
its map to storage handler could not find $docroot/foo/bar/hi.html, and it’s 
only later that my PerlTypeHandler sets the file to 
$docroot/$user/foo/bar/hi.html.

 You could also check how this directive affects the problem (whether it 
 should be turned off, or if your handler needs accept / deny the path info as 
 with the 'default' argument:
 AcceptPathInfo On
 I found this on apache 2.4's docs: 
 http://httpd.apache.org/docs/current/mod/core.html#AcceptPathInfo

No idea, I’m loathe to mess with it anymore.

David



smime.p7s
Description: S/MIME cryptographic signature

Re: How Do I change the Document Root Per Request

[David E. Wheeler]

On Mar 11, 2015, at 10:15 AM, Lathan Bidwell lat...@andrews.edu wrote:

 I am not an expert at this, so I don't have an answer.

Thanks for your reply, I appreciate it.

 But I can suggest a few debugging steps to clear out of the way:
 
 1) Confirm that your document root is showing properly in the error log
 Does the error log report /var/html/foo/bar.html is not found, or does it 
 only show the request? On my local apache instance if I do /blah/foo (non 
 existant), I get: File does not exist: /home/www/html/blah (which has my 
 document root in it). 

Yeah, the document root is correct.

 2) Confirm that path exists, Look for a folder structure you can create that 
 will work
 if /var/html/foo/bar.html doesn't exist, is it looking for 
 /var/www/foo/bar.html or /foo/bar.html

Yes, I was logging the value I was putting into filename(), and yes, it did 
exist.

 3) Do you have any rewrite urls or other location / directory directives that 
 could be overriding hits?
 Check your config files, and then put in some print STDERR / smart comments 
 to confirm if your routing program is returning the DECLINED

Nope.

 4) Does it work for DirectoryIndexes?

I don’t know, but it turns out that unsetting path_info() fixed the issue for 
me. How Apache uses filename and path_info together is opaque to me.

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: How Do I change the Document Root Per Request

[David E. Wheeler]

On Mar 11, 2015, at 9:59 AM, David E. Wheeler da...@justatheory.com wrote:

  # Set the filename.  
 
  my $file = File::Spec-catfile($sub_root, substr $r-uri, 1);
  $r-filename($file);
  $r-finfo(APR::Finfo::stat($file, APR::Const::FINFO_NORM, $r-pool));
  return DECLINED;
 }
 
 I have no PerlReponseHandler, so Apache handles the response…and returns 404. 
 Note that a request for /hi.txt; it’s only a request in a subdirectory, 
 /foo/bar.html, that fails. Why? Why isn’t Apache able to find that file? Is 
 there some other attribute of $r I need to set or unset?

Turns out I was able to fix this issue by unsetting path_info. I just added

$r-path_info(undef);

To the above code, and now Apache can find the file.

I do not understand the relationship between filename (which is often not the 
full path to a file) and path_info. Fortunately, it looks like I don’t have to. 
But we might want to consider updating the docs to recommend unsetting 
path_info when setting the full path to a file in filename.

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: How Do I change the Document Root Per Request

[David E. Wheeler]

On Mar 6, 2015, at 9:21 AM, David E. Wheeler da...@justatheory.com wrote:

 
   PerlMapToStorageHandler Apache2::Const::OK
 
 Otherwise it just fails super early. By adding this line, I am able to 
 freely set the filename later.
 
 Alas, this does *not* work for directory requests, just files. Directories 
 return 404. Is there some other attribute other than filename and finfo I 
 need to set so that, when I decline a request, Apache will find the directory 
 and use mod_autoindex to display it? It does do so if I remove the above 
 PerlMapToStorageHandler statement, so there must be some crucial attribute 
 that needs settings for it to find a directory, right?

I managed to fix this by changing my handler to a fixup handler and not setting 
any request handler at all. The fixup handler returns OK for HTML requests (it 
uses content negotiation and a GET param to decide what to return) and installs 
a relevant handler for other formats:

return OK if $format eq 'html';
$r-handler('modperl');
if ($format eq 'json') {
$r-set_handlers(PerlResponseHandler = \handle_json);
} elsif ($format eq 'xml') {
$r-set_handlers(PerlResponseHandler = \handle_xml);
} elsif ($format eq 'text') {
$r-set_handlers(PerlResponseHandler = \handle_text);
}

And now it works just how I want.

Thanks,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: How Do I change the Document Root Per Request

[David E. Wheeler]

On Mar 3, 2015, at 2:27 PM, David E. Wheeler da...@justatheory.com wrote:

 And now I got it to work. The key was to add.
 
PerlMapToStorageHandler Apache2::Const::OK
 
 Otherwise it just fails super early. By adding this line, I am able to freely 
 set the filename later.

Alas, this does *not* work for directory requests, just files. Directories 
return 404. Is there some other attribute other than filename and finfo I need 
to set so that, when I decline a request, Apache will find the directory and 
use mod_autoindex to display it? It does do so if I remove the above 
PerlMapToStorageHandler statement, so there must be some crucial attribute that 
needs settings for it to find a directory, right?

Thanks,

David

smime.p7s
Description: S/MIME cryptographic signature

Re: How Do I change the Document Root Per Request

[David E. Wheeler]

On Mar 2, 2015, at 9:35 PM, David E. Wheeler da...@justatheory.com wrote:

PerlLoadModule My::UserFixup
Location /
PerlFixupHandler  My::UserFixup
AuthType  Basic
AuthName  User File Service
Require   valid-user
/Location

I managed to get a little further by switching from PerlFixupHandler to 
PerlTypeHandler. I still get some 404s for files, but all the directories serve 
properly. As it happens, I have a response handler that handles directory 
requests, but it declines file requests. I assume, then, that the default 
Apache response handler doesn’t know that I’ve updated the filename. Is there 
some way to get it to do that?

Thanks,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: How Do I change the Document Root Per Request

[David E. Wheeler]

On Mar 3, 2015, at 11:34 AM, David E. Wheeler da...@justatheory.com wrote:

 I managed to get a little further by switching from PerlFixupHandler to 
 PerlTypeHandler. I still get some 404s for files, but all the directories 
 serve properly. As it happens, I have a response handler that handles 
 directory requests, but it declines file requests. I assume, then, that the 
 default Apache response handler doesn’t know that I’ve updated the filename. 
 Is there some way to get it to do that?

And now I got it to work. The key was to add.

PerlMapToStorageHandler Apache2::Const::OK

Otherwise it just fails super early. By adding this line, I am able to freely 
set the filename later.

Thanks,

David




smime.p7s
Description: S/MIME cryptographic signature

Re: How Do I change the Document Root Per Request

[David E. Wheeler]

On Mar 2, 2015, at 8:27 PM, Fred Moyer f...@redhotpenguin.com wrote:

 Can you show us your relevant httpd.conf snippet? No guesses right
 now, but that might help.

Sure.

PerlLoadModule My::UserFixup
Location /
PerlFixupHandler  My::UserFixup
AuthType  Basic
AuthName  User File Service
Require   valid-user
/Location

There’s also a simple PerlAuthenHandler. Pretty simple stuff.

I’ve gotten a little further since my post on Friday, changing the filename 
instead of the doc_root:

   sub handler {
   my $r = shift;

   # We only want to do this once per request.
   return DECLINED unless $r-is_initial_req;

   # Get the username.
   my $user = $r-user or return HTTP_UNAUTHORIZED;

   # Return forbidden if the subscriber ID subdirectory does not exist.
   my $doc_root = $r-document_root;
   my $sub_root = File::Spec-catdir($doc_root, $user);
   return HTTP_FORBIDDEN unless -d $sub_root;

   # Set the filename.  

   my $file = File::Spec-catfile($sub_root, substr $r-uri, 1);
   $r-filename($file);
   $r-finfo(APR::Finfo::stat($file, APR::Const::FINFO_NORM, $r-pool));
   return DECLINED;
  }

This works for root requests (/), but not anything else, which always return 
404. It’s driving me crazy. Maybe there’s something else i need to set? This 
has *got* to be a common thing people do, right? It’s driving me bananas (and 
towards Plack [again!]).

Thanks,

David



smime.p7s
Description: S/MIME cryptographic signature

How Do I change the Document Root Per Request

[David E. Wheeler]

Hi,

I want to set the document root for a request to map to the basic auth 
username. I tried this in a PerlFixupHandler:

sub handler {
my $r = shift;

# We only want to do this once per request.
return DECLINED unless $r-is_initial_req;

# Get the username.
my $user = $r-user or return HTTP_UNAUTHORIZED;

# Return forbidden if the username subdiectory does not exist.
my $doc_root = File::Spec-catdir($r-document_root, $user);
return HTTP_FORBIDDEN unless -d $doc_root;

# Set the document root for the duration of this request and return.
$r-document_root($doc_root);
return DECLINED;
}

But alas, it still serves the original document root. How can I get it to 
change the document root on a per-request basis? If I cant, should I change the 
URI or the filename, instead?

Thnks,

David

smime.p7s
Description: S/MIME cryptographic signature

Custom Configuration Best Practice

[David E. Wheeler]

Fellow mod_perlers,

I followed the instructions in the Server Configuration Customization guide to 
create a custom Apache configuration directive like so:

   my $foo;
   sub foo { $foo = $_[2] }
   Apache2::Module::add(__PACKAGE__, [
   { name = 'MyFoo', func = __PACKAGE__ . '::foo' },
   ]);

   sub handler {
   my $r = shift;
   $r-print($foo);
   return OK;
   }

This works pretty well; I can now set the MyFoo directive in my httpd.conf. But 
it feels a little hinky to set up package globals that get set on every request 
like this. It feels like it would make more sense if they were getting passed 
to an object method, but foo() is called as a function here; the first 
parameter is the class name, not an object. Also, I tried to use an anonymous 
sub in the add call:

   my $foo;
   Apache2::Module::add(__PACKAGE__, [
   { name = 'MyFoo', func = sub { $foo = $_[2] },
   ]);

But that didn’t work either; mod_perl complained that it couldn’t find a 
function named “CODE(0x1d5e988P)” in the package. I was surprised by this since 
the docs say:


 The func attribute expects a reference to a function or a function name. 


https://perl.apache.org/docs/2.0/user/config/custom.html#C_func_

So none of this feels quite right to me. Anyone got a point to best practices 
for setting up custom configuration directives? Or is this close to what 
everyone does anyway?

Thanks,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: Apache::DBI

[David E. Wheeler]

On Aug 2, 2011, at 6:30 AM, Feng He wrote:

 I just want to develop a modperl application.
 It's a handler, the database is Mysql.
 Shall I use Apache::DBI, or DBI is just fine ?

I recommend DBIx::Connector.

Best,

David

Re: Apache::DBI and DBIx::Class

[David E. Wheeler]

On Jun 28, 2011, at 11:34 AM, Dave Morgan wrote:

 First off, please let me apologize for the tone of my last email,
 It was certainly not what I intended.

No worries. I assumed it was a caffeine shortage. That's what I suffer from 
sometimes. :-)

 I have to stop having discussions about system design and
 philosophy after having meetings with a developer who's most
 intelligent statement was It works on my machine. Cold Fusion not
 mod-perl, and the problem is not with Cold Fusion.

Someone put cold fusion in your espresso. That can cause a bad day no question.

  IMHO, worth exactly what you paid for it
 This was meant to refer to my opinion, not your code, sorry.

Ah, okay.

 Never ran Bricolage in production. Did run a test system, ugh.
 I suspect the issue was with the Bricolage code, not Apache::DBI.

Based on what evidence, exactly?

 I have never used connect_cached, never had the need.

If you rely on Apache::DBI, you wouldn't need connect_cached, of course.

 Postgres supports it but DBD::Pg doesn't, not with the standard DBI
 fetch* APIs. At least as of last year it didn't. If I didn't have to spend
 all my time reviewing and running other peoples code  I would take the time
 to add the functionality.

What's wrong with SQL? Example:

#!/usr/local/bin/perl -w

use v5.14;
use utf8;
use DBI;

my $dbh = DBI-connect(
'dbi:Pg:dbname=try', '', '', {
PrintError= 0,
RaiseError= 1,
AutoCommit= 1,
pg_enable_utf8= 1,
pg_server_prepare = 0,
}
);

$dbh-begin_work;
$dbh-do('CREATE TABLE foo (id INT)');
$dbh-do('INSERT INTO foo VALUES (1), (2), (3), (4), (5), (6)');

$dbh-do('DECLARE getfoo CURSOR FOR SELECT id FROM foo');

my $sth = $dbh-prepare('FETCH FORWARD 2 FROM getfoo');
for (1..3) {
say $_;
$sth-execute;
while (my $r = $sth-fetch) {
say .. $r-[0];
}
}
$dbh-rollback;

Output:

1
.. 1
.. 2
2
.. 3
.. 4
3
.. 5
.. 6

 Well, DBIx::Connector does not do connection pooling (or caching), so that 
 wouldn't be a problem.
 
 I am being unclear here. Each apache child/process will open 2 connections, 
 one for
 Apache::DBI and one for DBIx::Class or DBIx::Connector.

DBIx::Connector disables Apache::DBI, so there should only be one. If not, 
there's a bug. Also, most folks who use DBIx::Connector don't use Apache::DBI 
at all.

 Possibly more connections if
 a variety of different modules are being used, each with it's own connection 
 handling.

Yes, that's a risk. Don't do that.

 This explains an issue I saw with a client 2 months ago where the number of 
 open database
 sessions doubled with the introduction of some new code based on DBIx::Class.

Sounds like a bug in DBIx::Class.

 I believed the doubling of sessions was a symptom of poor code. Neither I nor 
 their
 developers had any idea that Apache::DBI was being bypassed. Luckily it was a 
 prototype
 and the issue was caught while stress testing in their staging environment.

Yes, DBIx::Class should disable Apache::DBI when it does its connecting, just 
like DBIx::Connector does. Apache::DBI should still be usable if you're 
connecting by some means other than DBIx::Class. But this is one of the three 
raisons d'être for DBIx::Connector: Use it to connect instead of the DBI and do 
your own connection caching. I believe DBIx::Class will be switching to 
DBIx::Connector eventually.

 And so into the design and philosophy. As an admin I need to be able to 
 deploy code without
 side effects that may adversely affect other processes or the system itself.

Yeah, that's exactly the complaint about Apache::DBI. Its entire purpose is 
side-effects.

 Now at least you document your connection logic, so that if I do a quick 
 review I can see the
 implications (I doubt I would actually catch it but at least you are giving 
 me a chance :)
 whereas for DBIx::Class, if there is documentation about connecting I don't 
 know where it is.

Yeah, I had to do some mining to dig it out for DBIx::Connector.

 Even so, I believe the logic should be
   if Apache::DBI use it
   else use my stuff

IIRC, I can't use Apache::DBI and still support the ability to reconnect when a 
database connection has dropped. That's its second raison d'être (pings mostly 
go away when you use it in fixup mode, which is recommended).

 I do not know the internals of DBI or the derived classes so I do not know if 
 the above is
 practical. However, it is respectful of the environment it is going to run 
 in. Writing code
 that specifically ignores how a system is configured is ... impolite!

Well, one could interpret Apache::DBI as doing exactly the same thing. Someone 
loads it unbeknownst to you, and all of a sudden the behavior of DBI-connect 
is globally changed.

 And yet Apache::DBI also has side effects. I revoke ALTER SESSION from 

Re: How do you use mod_perl for your web application?

[David E. Wheeler]

On Jun 27, 2011, at 12:53 PM, Octavian Rasnita wrote:

 DBIx::Class already manages its connections for you, and therefore it
 cannot benefit from Apache::DBI under any scenario.  It makes one
 connection per-process, and keeps that connection persistent,
 reconnecting only if the connection appears to have died, or if you
 fork/thread over to another process/thread-id.  The only Apache::DBI
 issue in DBIx::Class is that Apache::DBI will actually thwart
 DBIx::Class's connection management code, and cause it to use the same
 (and invalid) connection in a new process, in cases such as (as
 mentioned above) if you make a DBI connection before forking in a
 prefork mod_perl server.
 
 To work around this, DBIx::Class has specific code in it to work
 around Apache::DBI, nullifying the effects of Apache::DBI on
 DBIx::Class.  Essentially, loading Apache::DBI should change nothing
 and be rather pointless under DBIx::Class.
 
 The only reason we support it (support working around it) is because
 someone might want Apache::DBI loaded up under the same mod_perl as a
 DBIx::Class application to support a different legacy application
 which does not use DBIx::Class, in which case they share a perl
 interpreter and will both have the same set of modules loaded.

The same statements apply to DBIx::Connector, FWIW.

Best,

David

Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for your web application?]

[David E. Wheeler]

On Jun 27, 2011, at 1:13 PM, Fred Moyer wrote:

 Wow, that's obnoxious:
 
 1237   if ($INC{'Apache/DBI.pm'}  $ENV{MOD_PERL}) {
 1238 $old_connect_via = $DBI::connect_via;
 1239 $DBI::connect_via = 'connect';
 1240   }

DBIx::Connector does the same thing.

 And it is also apparently not working as they expected:
 
 [Mon Jun 27 13:05:17 2011] [notice] Apache/2.2.17 (Unix)
 mod_apreq2-20090110/2.8.0 mod_perl/2.0.5 Perl/v5.12.3 configured --
 resuming normal operations
 8879 Apache::DBI new connect to 'dbname='...
 
 In my startup.pl (My::Model is DBIx::Class based):
 
 $Apache::DBI::DEBUG = 2;
 my $db_connect_params = My::Model-connect_params;
 Apache::DBI-connect_on_init( @{$db_connect_params} );
 Apache::DBI-setPingTimeOut( $db_connect_params-[0], 5 );
 
 # delete this line and I will beat you with a stick (note to self)
 My::Model-connect-disconnect;
 $DBI::connect_via = 'Apache::DBI::connect';

You lost me. But really, I strongly recommend against the use of Apache::DBI. 
Some discussion here:

  http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Connector.pm#Description

Best,

David

Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for your web application?]

[David E. Wheeler]

On Jun 27, 2011, at 1:40 PM, Dave Morgan wrote:

 You lost me. But really, I strongly recommend against the use of 
 Apache::DBI. Some discussion here:
 
   
 http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Connector.pm#Description
 
 
 And having read that, I strongly recommend against the use of DBIx-Connector.
 But then I'm just a production DBA :)

Me too. What weaknesses do you see in it?

Best,

David

Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for your web application?]

[David E. Wheeler]

On Jun 27, 2011, at 2:17 PM, Fred Moyer wrote:

 You lost me. But really, I strongly recommend against the use of 
 Apache::DBI. Some discussion here:
  http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Connector.pm#Description
 
 It seems like you are looking for a more feature rich db connection
 caching module as opposed to a drop in module for mod_perl.  For most
 mod_perl users, Apache::DBI provides a performance improvement with Pg
 and Oracle for just a few lines in your startup.pl.

No. DBIx::Connector doesn't do caching at all. That's the point, really.

Best,

David

Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for your web application?]

[David E. Wheeler]

On Jun 27, 2011, at 4:20 PM, Dave Morgan wrote:

 What's the point of it?

First of all, what Perrin said. :-)

 As far as I can see the author claims to have issues with Apache::DBI and 
 does not
 like the hidden aspect.

FWIW, I am the author.

 I have never experienced his issues and the hidden
 aspect is the good part. Apache::DBI can be deployed by an admin without
 consulting the developers, without affecting their code. It does not require
 any use statements in the source code.

Yeah, too magical. I removed support for it in Bricolage years ago, though I 
can't remember the details of why anymore. connect_cached() worked much better 
for me (though it's kind of a PITA to set up).

 He claims that it does no caching across threads. Why not? If the thread uses
 the same connection/session state then why not use a cached connection. If
 it doesn't then it is the developers responsibility.

Most database handles are not thread-safe.

 Transaction management: I cannot see the point of it, however, I can see the
 utility to others. My personal viewpoint is that a
   if good commit, else rollback
 make what's happening explicit which when dealing with a db is extremely 
 useful.

Yeah, that interface is a convenience. I think it's much nicer to scope things 
within a subref.

 Mind you I believe AutoCommit is a bad thing and should never have been made.

I don't think AutoCommit was a mistake. These days I always connect with 
AutoConnect explicitly set to true, as otherwise I might have a transaction 
running for a long time until the first connection comes in.

 My shop also use stored procs for almost everything. Wish DBD::Pg would let
 me read cursors, like DBD::Oracle, that's what I really need.

I don't understand. PostgreSQL supports cursors, and you can read from them 
using FETCH.

  http://www.postgresql.org/docs/current/static/sql-fetch.html

Might be my lack of knowledge of Oracle at work here, though.

 I suppose it is all a matter of personal preference but I have found that the
 further removed the developer is from the database the worse they are at 
 accessing
 it. DBIx::Class is the perfect example. Please spare me the hassle of trying
 to debug/explain/improve any code that uses that. I am sure that high quality
 code can be written using DBIx::Class but I have yet to see it.

Yes, I'm not a fan of ORMs because they tend to create bad queries, among other 
things. This is why DBIx::Connector is much more focused on adding interfaces 
to a connection, and not to querying the database.

 Oops, just realized you are the author :).

:-)

 Please don't take anything above
 personally, I just think that if you wanted transaction management, it would
 have been better to write a module that just does that and nothing else.
 Then, if a developer in my shop wanted to use it I could load it without
 having to worry about apache managing two connection pools.

Well, DBIx::Connector does not do connection pooling (or caching), so that 
wouldn't be a problem.

 IMHO, worth exactly what you paid for it

I paid quite a lot of it in terms of my time to develop the interface. So I'm 
rather fond of it. Varying opinions of course welcome.

Best,

David

Re: How do you use mod_perl for your web application?

[David E. Wheeler]

On Jun 21, 2011, at 9:33 AM, Cosimo Streppone wrote:

 Recently we have seen two friendly factions struggling
 for power :), one moving towards Catalyst/DBIx/TT2 and
 another testing Plack/PSGI.

To be clear, these two factions are orthogonal. FWIW, Catalyst is being updated 
to run on Plack.

Best,

David

Re: How do you use mod_perl for your web application?

[David E. Wheeler]

On Jun 16, 2011, at 12:14 PM, Perrin Harkins wrote:

 On Thu, Jun 16, 2011 at 12:01 AM, Fred Moyer f...@redhotpenguin.com wrote:
 I'm interested in hearing about what application frameworks (Catalyst,
 CGI::App, Mojolicious) are used here with mod_perl.
 
 Mason 1.x on mod_perl 1.x and apache 1.x, baby!

Whatever old man!

David

Re: How do you use mod_perl for your web application?

[David E. Wheeler]

On Jun 15, 2011, at 9:01 PM, Fred Moyer wrote:

 I'll start.  I have a couple of Apache::Dispatch based applications I
 wrote.  I also work on an Apache::ASP large codebase, and a couple of
 different Catalyst based systems.  All are running on mod_perl 2.0.4
 in production (the ops haven't upgraded to 2.0.5 yet).

I use Apache 2 as a reverse proxy for a bunch of Starman-powered Plack apps. 
And I have a Bricolage install on mod_perl2.

 If I were to migrate, I would probably try out something like
 Mojolicious on Plack on mod_perl2.  Performance of mod_perl2 has never
 been an issue to date, but I have Perlbal doing connection handling as
 a reverse proxy.

PGXN, which runs on Starman, will be moving to a PostgreSQL community server. I 
think they use Varnish for reverse proxying.

Best,

David

Build Failure on Perl 5.12 RC3

[David E. Wheeler]

Hey all,

I'm testing Perl 5.12 RC3 and ran into these errors when trying to build 
mod_perl 2 (mod_perl 1 built fine FWIW):

benedict ~/dev/perl/mod_perl-2.0 /usr/local/perl-5.12/bin/perl Makefile.PL 
MP_AP_PREFIX=/usr/local/apache2-test MP_PROMPT_DEFAULT=1
Reading Makefile.PL args from @ARGV
   MP_AP_PREFIX = /usr/local/apache2-test
   MP_PROMPT_DEFAULT = 1
no conflicting prior mod_perl version found - good.
Configuring Apache/2.2.13 mod_perl/2.0.5-dev Perl/v5.12.0
Use of uninitialized value in join or string at lib/Apache2/Build.pm line 900.
Use of uninitialized value in join or string at lib/Apache2/Build.pm line 900.
Checking if your kit is complete...
Looks good
Writing Makefile for Apache2::Reload
Use of uninitialized value in join or string at lib/Apache2/Build.pm line 900.
Use of uninitialized value in join or string at lib/Apache2/Build.pm line 900.
Checking if your kit is complete...
Looks good
Writing Makefile for Apache2::SizeLimit
Subroutine MY::postamble redefined at ./Makefile.PL line 167.
Subroutine MY::constants redefined at ./Makefile.PL line 181.
[   info] generating script t/TEST
[   info] generating script ./t/cgi-bin/cookies.pl
[   info] generating script ./t/cgi-bin/next_available_port.pl
Checking if your kit is complete...
Looks good
[   info] generating script t/TEST
Writing Makefile for Apache::TestItSelf
Writing Makefile for Apache::Test
Checking for File::Spec...ok
Checking for Cwd...ok
[   info] generating script t/TEST
Checking if your kit is complete...
Looks good
Writing Makefile for ModPerl::Registry
Writing Makefile for APR::Base64
Writing Makefile for APR::Brigade
Writing Makefile for APR::Bucket
Writing Makefile for APR::BucketAlloc
Writing Makefile for APR::BucketType
Writing Makefile for APR::Date
Writing Makefile for APR::Error
Writing Makefile for APR::Finfo
Writing Makefile for APR::IpSubnet
Writing Makefile for APR::OS
Writing Makefile for APR::Pool
Writing Makefile for APR::SockAddr
Writing Makefile for APR::Socket
Writing Makefile for APR::Status
Writing Makefile for APR::String
Writing Makefile for APR::Table
Writing Makefile for APR::ThreadMutex
Writing Makefile for APR::ThreadRWLock
Writing Makefile for APR::URI
Writing Makefile for APR::UUID
Writing Makefile for APR::Util
Writing Makefile for APR
Writing Makefile for Apache2::Access
Writing Makefile for Apache2::CmdParms
Writing Makefile for Apache2::Command
Writing Makefile for Apache2::Connection
Writing Makefile for Apache2::ConnectionUtil
Writing Makefile for Apache2::Directive
Writing Makefile for Apache2::Filter
Writing Makefile for Apache2::FilterRec
Writing Makefile for Apache2::HookRun
Writing Makefile for Apache2::Log
Writing Makefile for Apache2::MPM
Writing Makefile for Apache2::Module
Writing Makefile for Apache2::Process
Writing Makefile for Apache2::RequestIO
Writing Makefile for Apache2::RequestRec
Writing Makefile for Apache2::RequestUtil
Writing Makefile for Apache2::Response
Writing Makefile for Apache2::ServerRec
Writing Makefile for Apache2::ServerUtil
Writing Makefile for Apache2::SubProcess
Writing Makefile for Apache2::SubRequest
Writing Makefile for Apache2::URI
Writing Makefile for Apache2::Util
Writing Makefile for Apache2
Writing Makefile for ModPerl::Global
Writing Makefile for ModPerl::Util
Writing Makefile for ModPerl
Writing Makefile for ModPerl::WrapXS
Writing Makefile for APR
Writing Makefile for APR::Const
Writing Makefile for APR::PerlIO
Writing Makefile for libaprext
Writing Makefile for APR_build
Writing Makefile for Apache2::Const
Writing Makefile for Apache2_build
Writing Makefile for ModPerl::Const
Writing Makefile for ModPerl
Writing Makefile for ModPerl::XS
Writing Makefile for mod_perl2
[warning] mod_perl dso library will be built as mod_perl.so
[warning] You'll need to add the following to httpd.conf:
[warning] 
[warning]   LoadModule perl_module modules/mod_perl.so
[warning] 
[warning] depending on your build, mod_perl might not live in
[warning] the modules/ directory.

benedict ~/dev/perl/mod_perl-2.0 make -j3
cd src/modules/perl  make
cc -I/Users/david/dev/perl/mod_perl-2.0/src/modules/perl 
-I/Users/david/dev/perl/mod_perl-2.0/xs -I/usr/local/apache2-test/include 
-I/usr/local/apache2-test/include  -I/usr/local/apache2-test/include 
-fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe 
-fstack-protector -I/usr/local/include 
-I/usr/local/perl-5.12/lib/5.12.0/darwin-multi-2level/CORE -DMOD_PERL 
-DMP_COMPAT_1X -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -O3  \
-c mod_perl.c  mv mod_perl.o mod_perl.lo
cc -I/Users/david/dev/perl/mod_perl-2.0/src/modules/perl 
-I/Users/david/dev/perl/mod_perl-2.0/xs -I/usr/local/apache2-test/include 
-I/usr/local/apache2-test/include  -I/usr/local/apache2-test/include 
-fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe 
-fstack-protector -I/usr/local/include 
-I/usr/local/perl-5.12/lib/5.12.0/darwin-multi-2level/CORE -DMOD_PERL 
-DMP_COMPAT_1X -DDARWIN 

Re: Build Failure on Perl 5.12 RC3

[David E. Wheeler]

On Apr 5, 2010, at 6:20 PM, Fred Moyer wrote:

 Builds ok here on OS X 10.6.3 (tests don't start yet though).  Wonder
 what the difference in our setups 

Okay, Fred and I have been hacking on this for a few hours, and thanks to a tip 
from Stefan O'Rear on #p5p, we've been able to trace the basic problem.

I can get mod_perl2 to build with Perl configured with:

sh Configure -des -Duseshrplib

Or

sh Configure -des -Duseshrplib -Dusemultiplicity -Duseithreads

But not

sh Configure -des -Duseshrplib -Dusemultiplicity

That is, mod_perl will build with both multiplicity and ithreads or with 
neither, but not with multiplicity only. With multiplicity-only, I get:

mod_perl.c: In function ‘modperl_shutdown’:
mod_perl.c:62: error: ‘my_perl’ undeclared (first use in this function)
mod_perl.c:62: error: (Each undeclared identifier is reported only once
mod_perl.c:62: error: for each function it appears in.)

Fred says this is the relevant code:

#ifndef USE_ITHREADS
static apr_status_t modperl_shutdown(void *data)
{
modperl_cleanup_data_t *cdata = (modperl_cleanup_data_t *)data;
PerlInterpreter *perl = (PerlInterpreter *)cdata-data;
void **handles;

handles = modperl_xs_dl_handles_get(aTHX);

And what Stefan says is: “you need to change your function declaration from 
...(void *arg) to ...(pTHX_  void *arg)”.

I believe Fred managed to get past some of these errors by doing something like 
this. Fred, can you confirm?

So there you have it. If you build perl with

sh Configure -des -Duseshrplib -Dusemultiplicity

and build mod_perl 2 against that, you should be able to replicate this issue.

Anyone familiar with this stuff and able to fix? I'd love to see mod_perl 2.05 
drop when Perl 5.12.0 final drops (next week, I believe).

Thanks,

David

PS: I think the apreq stuff needs to be hit with the same multiplicity 
cluestick -- anyone know that code?

Re: Error: `PL_sv_yes' can not be used when making a shared object; recompile with -fPIC

[David E. Wheeler]

On Feb 25, 2010, at 3:30 PM, Fred Moyer wrote:

 On Thu, Feb 25, 2010 at 3:11 PM, David E. Wheeler da...@kineticode.com 
 wrote:
 On Feb 25, 2010, at 3:03 PM, Fred Moyer wrote:
 
 Absolute - maybe in the INSTALL file?  You have commit access right?
 
 Only to documentation IIRC. I got it just about the time I stopped writing 
 docs. ;-)
 
 I'd suggest either of these pod files:
 
 For an even more detailed documentation refer to:
 
  docs/user/install/install.pod
  docs/user/config/config.pod

Done in r921489. config.pod looks like it's only for configuring mod_perl2 to 
run, not for building mod_perl (or Perl), so I've only added a note to 
install.pod.

BTW, that doc looks different than what's on the site. Does the site need to be 
updated?

Best,

David

Re: Error: `PL_sv_yes' can not be used when making a shared object; recompile with -fPIC

[David E. Wheeler]

On Feb 24, 2010, at 11:31 AM, David E. Wheeler wrote:

 export CFLAGS='-m64 -mtune=nocona'; export LDFLAGS='-L/usr/lib64'
 ./Configure -des -A ccflags=-fPIC -Dprefix=/opt/perl
 -Dinstallprefix=/opt/perl
 
 Is that for Perl or for mod_perl? Looks like Perl.

seems to have worked by rebuilding Perl with:

CFLAGS='-m64 -mtune=nocona' ./Configure -des -A ccflags=-fPIC

Should this perhaps be documented somewhere?

I did get a couple of test failures though:

t/hooks/authen_basic.t .. 
1..4
# Running under perl version 5.010001 for linux
# Current time local: Thu Feb 25 16:50:03 2010
# Current time GMT:   Thu Feb 25 21:50:03 2010
# Using Test.pm version 1.25_02
# Using Apache/Test.pm version 1.31
ok 1
ok 2
ok 3
not ok 4
# Failed test 4 in t/hooks/authen_basic.t at line 26
Failed 1/4 subtests 
...
t/hooks/authz.t . 
1..4
# Running under perl version 5.010001 for linux
# Current time local: Thu Feb 25 16:50:04 2010
# Current time GMT:   Thu Feb 25 21:50:04 2010
# Using Test.pm version 1.25_02
# Using Apache/Test.pm version 1.31
ok 1
ok 2
ok 3
not ok 4
# Failed test 4 in t/hooks/authz.t at line 19
Failed 1/4 subtests 

Error log attached.

Thanks,

David



error_log.gz
Description: GNU Zip compressed data

Re: Error: `PL_sv_yes' can not be used when making a shared object; recompile with -fPIC

[David E. Wheeler]

On Feb 25, 2010, at 3:03 PM, Fred Moyer wrote:

 Absolute - maybe in the INSTALL file?  You have commit access right?

Only to documentation IIRC. I got it just about the time I stopped writing 
docs. ;-)

Best,

David

Re: Error: `PL_sv_yes' can not be used when making a shared object; recompile with -fPIC

[David E. Wheeler]

On Feb 24, 2010, at 12:07 AM, Fred Moyer wrote:

 Haven't tried with 5.10.1, but here's my 5.8.8/2.0.4/2.2.8 settings:
 
 perl -V | grep -i fpic
cc='cc', ccflags ='-fPIC -D_LARGEFILE_SOURCE
 -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
cppflags='-fPIC -I/usr/include/gdbm'
cccdlflags='-fpic', lddlflags='-shared'
 
 Have you tried passing -fPIC at perl configure time when it asks for
 additional CFLAGS?

I've been using -des, but I'll have a look at it. How are you configuring?

Best,

David

Re: Error: `PL_sv_yes' can not be used when making a shared object; recompile with -fPIC

[David E. Wheeler]

On Feb 24, 2010, at 10:19 AM, Serge Ivanchenko wrote:

 Try this:
 
 export CFLAGS='-m64 -mtune=nocona'; export LDFLAGS='-L/usr/lib64'
 ./Configure -des -A ccflags=-fPIC -Dprefix=/opt/perl
 -Dinstallprefix=/opt/perl

Is that for Perl or for mod_perl? Looks like Perl.

Best,

David

Error: `PL_sv_yes' can not be used when making a shared object; recompile with -fPIC

[David E . Wheeler]

Fellow mod_perlers,

I found myself getting this error with mod_perl 2 on 64 bit CentOS this evening:

bash-3.2# make test
cd src/modules/perl  make
make[1]: Entering directory `/home/dwheeler/mod_perl-2.0.4/src/modules/perl'
rm -f mod_perl.so
cc -shared -O2 -L/usr/local/lib -fstack-protector \
 \
mod_perl.lo modperl_interp.lo modperl_tipool.lo modperl_log.lo 
modperl_config.lo modperl_cmd.lo modperl_options.lo modperl_callback.lo 
modperl_handler.lo modperl_gtop.lo modperl_util.lo modperl_io.lo 
modperl_io_apache.lo modperl_filter.lo modperl_bucket.lo modperl_mgv.lo 
modperl_pcw.lo modperl_global.lo modperl_env.lo modperl_cgi.lo modperl_perl.lo 
modperl_perl_global.lo modperl_perl_pp.lo modperl_sys.lo modperl_module.lo 
modperl_svptr_table.lo modperl_const.lo modperl_constants.lo 
modperl_apache_compat.lo modperl_error.lo modperl_debug.lo 
modperl_common_util.lo modperl_common_log.lo modperl_hooks.lo 
modperl_directives.lo modperl_flags.lo modperl_xsinit.lo modperl_exports.lo  
-Wl,-E  -fstack-protector -L/usr/local/lib  
-L/usr/local/lib/perl5/5.10.1/x86_64-linux/CORE -lperl -lnsl -ldl -lm -lcrypt 
-lutil -lc \
-o mod_perl.so
/usr/bin/ld: /usr/local/lib/perl5/5.10.1/x86_64-linux/CORE/libperl.a(op.o): 
relocation R_X86_64_32S against `PL_sv_yes' can not be used when making a 
shared object; recompile with -fPIC
/usr/local/lib/perl5/5.10.1/x86_64-linux/CORE/libperl.a: could not read 
symbols: Bad value
collect2: ld returned 1 exit status
make[1]: *** [mod_perl.so] Error 1
make[1]: Leaving directory `/home/dwheeler/mod_perl-2.0.4/src/modules/perl'
make: *** [modperl_lib] Error 2

Really annoying. A Googling turned up this post from January:

  http://www.gossamer-threads.com/lists/modperl/modperl/100854

Too bad there was never a reply. Anyway, I can say that I set 

export CFLAGS=-fPIC

Before I built everything on this box, including Perl and Apache 2. Perl says:

bash-3.2# perl -V | grep PIC
cccdlflags='-fPIC', lddlflags='-shared -O2 -g -pipe -Wall 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m64 -mtune=generic'

So I'm at a loss here. Any ideas? mod_perl 2.04, perl 5.10.1, apache 2.2.14, 
all compiled from source.

Thanks,

David

Re: Redirect WTF

[David E. Wheeler]

On Jan 27, 2010, at 7:23 AM, Adam Prime wrote:

 This smells like a UseCanonicalName On + mod_dir redirect to me.  If the 
 directory /admin/profile/dest exists in the document root, there's a good 
 chance it is.

Ooh, thanks! I can see that I have mod_dir as a DSO, but I'm not loading it. 
The only modules loaded are:

LoadModule   perl_module /usr/local/apache2/modules/mod_perl.so
LoadModule   expires_module modules/mod_expires.so
LoadModule   apreq_module modules/mod_apreq2.so

Might the core be loading it somehow?

Thanks,

Daivd

Redirect WTF

[David E. Wheeler]

Fellow mod_perlers,

Here's a weird one for you. I'm testing Bricolage on mod_perl 2, getting it 
ready for release, and noticed that some sort of redirect is happening when I 
don't expect it.

To whit, I have this configuration:

NameVirtualHost *:80
VirtualHost *:80
  DocumentRoot   /usr/local/bricolage/comp
  ServerName benedict.local
  DefaultTypetext/html; charset=utf-8
  AddDefaultCharset  utf-8
  SetHandler modperl
  PerlResponseHandlerBric::App::Handler
  PerlAccessHandler  Bric::App::AccessHandler
  PerlCleanupHandler Bric::App::CleanupHandler
  PerlOptions+GlobalRequest
  RedirectMatch  permanent .*\/favicon\.ico$ 
http://benedict.local/media/images/bricicon.ico
  TraceEnableoff
  PerlTransHandler   Bric::App::PreviewHandler::uri_handler
  Location /logout
PerlAccessHandler   Bric::App::AccessHandler::logout_handler
PerlCleanupHandler  Bric::App::CleanupHandler
  /Location
  Location /login
SetHandler  modperl
PerlAccessHandler   Bric::App::AccessHandler::okay
PerlResponseHandler Bric::App::Handler
PerlCleanupHandler  Bric::App::CleanupHandler
  /Location
  Location /media
SetHandler  default-handler
PerlAccessHandler   Apache2::Const::OK
PerlCleanupHandler  Apache2::Const::OK
  /Location
  Location /media/js
ForceType   text/javascript; charset=utf-8
  /Location
  Location /media/css
ForceType   text/css
  /Location
  Location /data
SetHandler  default-handler
  /Location
  Location /soap
SetHandler  modperl
PerlResponseHandler Bric::SOAP::Handler
PerlAccessHandler   Apache2::Const::OK
  /Location
  Location /dist
SetHandler  modperl
PerlResponseHandler Bric::Dist::Handler
  /Location
  Location /data/preview
ExpiresActive   On
ExpiresDefault  now plus 0 seconds
PerlFixupHandlerApache2::Const::OK
  /Location
/VirtualHost

Note that the hosthame is benedict.local. Now I often just use localhost when 
using Bricolage, and most of the time that works fine. But there is one 
JavaScript-triggered redirect button that looks like this:

window.location.href = '/admin/profile/dest?id=1024'

And when I click it, The request goes to mod_perl and I see it come through the 
access handler and the fixup handler as a request to localhost. But then the 
PerlReponseHandler never fires! Instead, I see another request come in for the 
same URL path, but this time for the host name benedict.local. It's almost as 
if something in Apache or mod_perl is seeing that the request is for a 
different domain name and helpfully trying to redirect. But it's not helpful (I 
get a new login screen), and I don't understand why the same thing doesn't 
happen for other requests.

Is there something like that in mod_perl2 and I'm just missing it? Or is it 
more likely that there's some other mysterious bit of code in Bricolage that's 
doing it and I just haven't found it yet? If the latter, what comes between the 
PerlFixupHandler and PerlResponseHandler? Because in that first request, the 
fixup handler fires but the response handler never does.

TIA,

David

Re: Redirect WTF

[David E. Wheeler]

On Jan 26, 2010, at 3:18 PM, Fred Moyer wrote:

 I don't know if this could be an issue, but if I were to write this
 config snippet, I would create a root Location / block, and put the
 transhandler outside that (with the other location based directives
 inside).

The transhandler isn't used in production Bricolage installs, so I'm not too 
worried about it. It's mostly just there for folks evaluating Bricolage, as it 
manages a sort of internal preview server. Production installs turn that off 
and use an external server for previews.

Thanks,

David

Re: DBI Connectons accumulate under Mod_perl

[David E. Wheeler]

On Nov 16, 2009, at 1:10 AM, Artem Kuchin wrote:

 I am the original poster. Someone else has stolen my thread.
 Anyway.
 I AM calling disconnect  and the thing is wrapped in
 sub handler {
   my $db=...
 
   ...
 
   $db-disconnect();
 }
 
 So, everything goes out of scope when handler finishes. I made it so to play 
 nice with mod_per. NO globals
 at all.
 
 The apache run two site with such code. One site does not have a problem 
 another builds up the connection.
 It might be related to windows (it is all under windows and i never had such 
 problem under freebsd).

Maybe you have a system call or some other forking call that can lead to stray 
handles? Some Perl modules will do it without you knowing. I suggest switching 
to DBIx::Connector, which detects such things, to see if it helps.

Best,

David

Re: DBI Connectons accumulate under Mod_perl

[David E. Wheeler]

On Nov 13, 2009, at 1:47 AM, Artem Kuchin wrote:

 Might you have connections starting in parent processes and not getting 
 dropped? Are you using Apache::DBI or DBI-connect_cached or DBIx::Connector?
 
 Best,
 
 David
  
 Nope, i don't use those. Just plain DBI. Parent process does not open up any 
 connections.

Then you need to call DBI-disconnect when a process shuts down.

Best,

David

Re: DBI Connectons accumulate under Mod_perl

[David E. Wheeler]

On Nov 10, 2009, at 9:34 PM, Kulasekaran, Raja wrote:

 I'm connecting against oracle. So for every request it establish the
 connection and it remains stable even though the request 
 has been completed successfully . 

That sounds right, as the Apache process that handles the requests will stick 
around to handle more requests. But when that process dies, it should 
disconnect from the database. Does it?

Best,

David

Re: DBI Connectons accumulate under Mod_perl

[David E. Wheeler]

On Nov 11, 2009, at 6:22 PM, Kulasekaran, Raja wrote:

 No. I could see that oracle instances are still alive. 

That shouldn't be, of course. Did you run the DBI trace mode as Perrin 
suggested?

Best,

David

Re: DBI Connectons accumulate under Mod_perl

[David E. Wheeler]

On Nov 10, 2009, at 7:04 AM, Artem Kuchin wrote:

 You mean each child process creates a new database CONNECTION (not process) ?
 The process is just one multhreaded mysql. But this is exactly what i want. I 
 do not want any
 connection sharing because of the locking issues (lock tables). But they 
 still accumulate and after a
 couple of hours mysql runs out of connections. The weirdest thing is that 
 there are two sites, running
 pretty much the same software (minor changes to user part, no changes to db 
 part). Connections
 from one site accumulate, connection from other site do not accmulate - 
 disconnect work fine.

Might you have connections starting in parent processes and not getting 
dropped? Are you using Apache::DBI or DBI-connect_cached or DBIx::Connector?

Best,

David

Re: DBI Connectons accumulate under Mod_perl

[David E. Wheeler]

On Nov 10, 2009, at 9:19 AM, Kulasekaran, Raja wrote:

 I'm using Apache::DBI and DBI-connect (persistence connection) 
 
 So, Do I need to call $dbh-disconnect() for each child to close the
 connection ?

No, because Apache::DBI turns it into a no-op.

Apache::DBI is a very weird beast, with unanticipated action-at-a-distance 
issues that crop up here and there. It's crazy stuff like this that led me to 
abandon it -- at first for DBI-connect_cached (though I had to do some extra 
work to make sure it was safe), and more recently for DBIx::Connector, which 
does that extra work for me.

Can you see what PIDs MySQL is accepting connections from? Are they the same as 
currently-running Apache processes? Or are (some of them) from dead Apache 
child processes?

Best,

David

Re: Alternatives to Apache::DBI?

[David E. Wheeler]

On Oct 4, 2009, at 10:17 AM, Bill Moseley wrote:

This looks nice.  Thanks.  I don't use Apache::DBI, but this will be  
good
for general connection and transaction support.  I simply use  
connect_cached

now with { privite_pid = $$ } but that doesn't allow me to set
InactiveDestroy (although I'm not using $dbh in Apache parent or  
forking

children so has not been an issue).


Yeah, in that case, unless you want the transaction management or the  
saving of the overhead of ping(), as long as you're not doing anything  
in the parent process, I think what you've got is just fine. Very  
simple.


I'm not quite sure how to handle the pings.  I also don't like the  
idea of a

ping every time a $dbh is needed.   But, I wonder about re-issuing the
query.


Yes, you only want to do this if re-executing the code reference has  
no side-effects.


If a do() throws an exception and then the connection is tested and  
fails

the ping are you sure that the query didn't complete?  My concern, of
course, is running the query successfully twice.


I stole this code from DBIx::Class, which as you likely know, is  
pretty widely used. This was their approach, and I think it works well  
for them. But even better is to use txn_do() instead, as it should  
avoid the possibility of executing the query twice.



At one time I considered inspecting the error message and trying to
determine if it came from the database so that I knew the query  
failed, and

then reconnect and rerun the query, otherwise just die.

Obviously, you can't reissue the query if in a transaction -- and I  
see you

check for this.


Yep.


Checking the ping before returning $dbh isn't fool proof either.  The
connection could always die between the ping and then when $dbh is  
used.


Yet this is how the vast majority of database caching approaches work,  
including Apache::DBI and connect_cached(). I don't think that's worth  
worrying about, frankly.


Is the history of the ping to catch connections that have been  
inactive for
a long period and perhaps timed out?  I've thought about only  
issuing the

ping if the $dbh hasn't been fetched in some amount of time (say a few
minutes) to effectively disable the pings when the site is busy (which
should be most of the time).


I think that would be more complicated; you'd have to do more record- 
keeping. And then what do you do when you don't check it but a  
reconnect would allow you to continue?


But, if you use txn_do() for all transactions then is there any need  
for the

cleanup handler rollback?


No.

I also see in your disconnect method that you manually issue a  
rollback,
call disconnect and then undefine $dbh.  Doesn't DBI do that  
automatically

when $dbh is DESTROYed?


Probably, unless InactiveDestroy is set. That's more code I borrowed  
from DBIx::Class.


Best,

David

Re: Alternatives to Apache::DBI?

[David E. Wheeler]

On Oct 3, 2009, at 5:25 AM, Perrin Harkins wrote:


It's safe to create a connection on
startup with DBIx::Connection though, as it is careful not to cache  
across

fork or thread boundaries.


It may be necessary to set InactiveDestroy on any handles you open
during startup, even if you avoid ever using them again.  They will
eventually time out and may cause trouble when the database tries to
clean them up.


I realized, reading this, that I should check for the Apache startup  
and not cache things if it's during startup. That's useful under  
mod_perl, and won't hurt anything elsewhere. I'll get that committed  
this weekend.


But yes, when DBIx::Connection detects that it's in a new process and  
expires the cached handle, it first sets InactiveDestroy to true. So  
we should be good there.


Best,

David

Re: Alternatives to Apache::DBI?

[David E. Wheeler]

On Oct 3, 2009, at 2:00 PM, Perrin Harkins wrote:

I realized, reading this, that I should check for the Apache  
startup and not
cache things if it's during startup. That's useful under mod_perl,  
and won't

hurt anything elsewhere. I'll get that committed this weekend.


That should work.  Or you could have it close all connections at the
end of startup.


In PerlPostConfigHandler? Don't see anything like that in mod_perl1.  
My mod_perl foo is getting rusty, I gotta admit.


David

Re: Alternatives to Apache::DBI?

[David E. Wheeler]

On Oct 2, 2009, at 9:30 AM, Kurt Hansen wrote:

I'm wondering what techniques folks are using to get persistent  
database connections other than Apache::DBI.


I plan to release a new module, DBIx::Connection, on Monday. It's  
based on the connection caching stuff in DBIx::Class, and also has  
some nice transaction management stuff, so you might want to [check it  
out](http://github.com/theory/dbix-connection/).


Right now, following DBIx::Class's precedent, it disables Apache::DBI  
when it connects to the database. That may or may not be something I  
want to revisit, but since DBIx::Connection does its own caching, I  
rather suspect it's best not to also cache with Apache::DBI.


If you use it, you might also want install your own cleanup handler  
to issue a rollback on all open database handles at the end of every  
web request, as Perrin says. Bricolage does that with its use of  
connect_cached(), and that works great. It's safe to create a  
connection on startup with DBIx::Connection though, as it is careful  
not to cache across fork or thread boundaries.


Critiques welcome, BTW. I'll likely blog about it next week, too.

Best,

David

Re: [Fwd: Re: ports/134749: www/mod_perl bus error after 1.31 update]

[David E. Wheeler]

On Jun 4, 2009, at 11:26 PM, Philip M. Gollucci wrote:


fixed


Hrm. I wonder if it will fix [this error](http://www.mail-archive.com/d...@perl.apache.org/msg12057.html 
) as well?


Best,

David

Re: [Fwd: Re: ports/134749: www/mod_perl bus error after 1.31 update]

[David E. Wheeler]

On Jun 5, 2009, at 11:08 AM, Philip M. Gollucci wrote:


It might, but I don't think its related

I can test it here
Darwin clarus.apache.org. 8.11.0 Darwin Kernel Version 8.11.0: Wed  
Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power  
Macintosh powerpc


whenever I get a moment unless you beat me to it, but really I wish  
1.3 would die.


Oh, the bus error I reported last year was in 2.0.4…

David

Re: [RELEASE CANDIDATE] mod_perl-1.31 RC7

[David E. Wheeler]

On Apr 2, 2009, at 10:42 AM, Philippe M. Chiasson wrote:

The mod_perl 1.31 release candidate 7 is ready. It can be downloaded  
here:


http://www.apache.org/~gozer/mp1/mod_perl-1.31-rc7.tar.gz


I'm still getting a failure to make. :-(

% perl -v | grep This
This is perl, v5.10.0 built for darwin-2level
% uname -a
Darwin benedict.local 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24  
17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386

% USER=dougm /usr/local/bin/perl Makefile.PL \
  USE_APXS=1 \
  WITH_APXS=/usr/local/apache/bin/apxs \
  USE_DSO=1 \
  EVERYTHING=1
Will configure via APXS (apxs=/usr/local/apache/bin/apxs)
Will configure via APACI (DSO enabled)
PerlDispatchHandler.enabled
PerlChildInitHandlerenabled
PerlChildExitHandlerenabled
PerlPostReadRequestHandler..enabled
PerlTransHandlerenabled
PerlHeaderParserHandler.enabled
PerlAccessHandler...enabled
PerlAuthenHandler...enabled
PerlAuthzHandlerenabled
PerlTypeHandler.enabled
PerlFixupHandlerenabled
PerlHandler.enabled
PerlLogHandler..enabled
PerlInitHandler.enabled
PerlCleanupHandler..enabled
PerlRestartHandler..enabled
PerlStackedHandlers.enabled
PerlMethodHandlers..enabled
PerlDirectiveHandlers...enabled
PerlTableApienabled
PerlLogApi..enabled
PerlUriApi..enabled
PerlUtilApi.enabled
PerlFileApi.enabled
PerlConnectionApi...enabled
PerlServerApi...enabled
PerlSectionsenabled
PerlSSI.enabled
Will run tests as User: 'nobody' Group: 'wheel'
Configuring mod_perl for building via APXS
 + Creating a local mod_perl source tree
 + Setting up mod_perl build environment (Makefile)
 + id: mod_perl/1.31-rc7
 + id: Perl/v5.10.0 (darwin) [/usr/local/bin/perl]
Now please type 'make' to build libperl.so
Checking CGI.pm VERSION..ok
Checking for LWP::UserAgent..ok
Checking for HTML::HeadParserok
Checking if your kit is complete...
Looks good
Writing Makefile for Apache
Writing Makefile for Apache::Connection
Writing Makefile for Apache::Constants
Writing Makefile for Apache::File
Writing Makefile for Apache::Leak
Writing Makefile for Apache::Log
Writing Makefile for Apache::ModuleConfig
Writing Makefile for Apache::PerlRunXS
Writing Makefile for Apache::Server
Writing Makefile for Apache::Symbol
Writing Makefile for Apache::Table
Writing Makefile for Apache::URI
Writing Makefile for Apache::Util
Writing Makefile for mod_perl
% make
(cd ./apaci  PERL5LIB=/usr/local/src/mod_perl-1.31-rc7/lib: make)
make[1]: *** No rule to make target `libperl.so', needed by `lib'.   
Stop.

make: *** [apxs_libperl] Error 2

Re: [RELEASE CANDIDATE] mod_perl-1.31 RC7

[David E. Wheeler]

On Apr 2, 2009, at 7:29 PM, Philippe M. Chiasson wrote:

Now that I've had a chance to look into this, I swear I've debugged  
this

problem before, and I just can't find trace of it, or no patches.


Yeah, I first reported it a year ago, with RC4.


In any case, can you try this 1-liner patch? I believe it would do the
trick just fine, it's because on OS X there are .so/.dylib/.bundles  
and
we made the wrong assumption that perl's dlext would always be .so,  
but

it's not on recent OS X, it's .bundle.

The simplest trick I can think of is to just blindly normalize perl's
dlext to .so, and it works just fine. It's not that important, as that
value is only used to pick the right libperl.* make rule to build  
libperl,

so should be safe.


That seems to work great. My server didn't start for the tests, but it  
looks like Apache::Test is using the system apache instead of my  
build; I can look into that in the morning, but at least it builds  
now. Yay!


Best,

David

Re: [RELEASE CANDIDATE] mod_perl-1.31 RC7

[David E. Wheeler]

On Apr 2, 2009, at 8:38 PM, Philippe M. Chiasson wrote:

APXS/DSO make test was never supported, and needs some magic to get  
it to

work. USER=dougm is not enough...


I could have sworn I got it to work before; I'm getting this:

/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t 
/bin/sh: /httpd: No such file or directory

Which tells me that it's trying to use the wrong httpd. Which is odd,  
because ~/.apache-test/Apache/TestConfigData.pm has the right one.


Best,

David

Re: [RELEASE CANDIDATE] mod_perl-1.31 RC7

[David E . Wheeler]

On Apr 2, 2009, at 9:48 PM, David E. Wheeler wrote:


On Apr 2, 2009, at 8:38 PM, Philippe M. Chiasson wrote:

APXS/DSO make test was never supported, and needs some magic to get  
it to

work. USER=dougm is not enough...


I could have sworn I got it to work before; I'm getting this:

/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t 
/bin/sh: /httpd: No such file or directory

Which tells me that it's trying to use the wrong httpd. Which is  
odd, because ~/.apache-test/Apache/TestConfigData.pm has the right  
one.


Oh, I see, it's using $(APACHE_SRC)/$(HTTPD). Yes, I can see how that  
wouldn't work. :-)


Best,

David

Re: mod_perl handler and PHP

[David E. Wheeler]

On Mar 17, 2009, at 9:21 AM, daniel.angil...@imperia.net wrote:


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


You can if you write a perl filter that uses PHP::Interpreter to  
execute some code that parses your mod_perl output.


Best,

David

Re: mod_perl survey results

[David E. Wheeler]

On Nov 10, 2008, at 3:46 AM, André Warnier wrote:

- the rate of new people coming into the community has been  
declining.


The responses there are indeed a bit scary.  It feels like we're a  
dying breed.
I believe this is to a large extent a marketing issue for perl in  
general, and mod_perl by extension, with regard to the younger  
programmers generation.  At least in various European countries I  
know, perl is not really being taught in programming schools as a  
serious programming language for applications. These young people  
have all heard the name, but seem to consider it as a powerful but  
somewhat messy scripting language to create system administration  
scripts.


Frankly, I think that a lot of people thing that Apache/mod_perl is  
much too big and complex. They tend to prefer small single-process  
servers, like mongrel, running on lots of ports. FastCGI has many  
fans, as well. Even AxKit ships with its own fast and light Web  
server. For adherents of the fast and light server (handle HTTP and  
get out of my way!), Apache/mod_perl just seems like overkill.


To a certain degree, Apache/mod_perl is a victim of the success of  
HTTP. It's fairly easy to implement a new HTTP server, so there are a  
lot of them, and many are easy to use and extremely fast. If all  
you're interested in is serving a Rails or Catalyst app, Apache/ 
mod_perl starts to seem like much too big a beast.


Personally, I'm still a fan. But there are a lot of other attractive  
options out there, and, as has been pointed out elsewhere in this  
thread, folks who like and use mod_perl seem more interested in  
getting their jobs done than in evangelizing or marketing. Can't say I  
blame them.


Best,

David

Re: mod_perl survey results

[David E. Wheeler]

On Nov 11, 2008, at 10:15 AM, Perrin Harkins wrote:


I'm fine with people using other open source tools to get where they
want to go but the justifications they make about mod_perl being
heavier or slower rarely have any actual research behind them.


Yeah, I wasn't making the case for mongrel or lighthttpd myself. I  
still prefer mod_perl. But that argument is out there.



Hmm, this is making me want to run benchmarks!  Maybe a solid set of
benchmarks would be a fun OSCON presentation next year.


Great idea.

Best,

David

Re: mod_perl BOF at YAPC::NA

[David E. Wheeler]

On Jun 5, 2008, at 12:09, Perrin Harkins wrote:

On Sat, May 31, 2008 at 7:59 PM, Adam Prime [EMAIL PROTECTED]  
wrote:
YAPC::NA is only a few weeks away, and I stumbled upon the  
beginning of

plans for a BOF there.


Count me in.  This should be fun.  Work on your mod_php jokes.


I'll be there, too.

David

Re: TODO for 2.0.5

[David E. Wheeler]

On May 15, 2008, at 11:37, Philip M. Gollucci wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

1) MANIFEST verification checking for A-SL, A-Reload and anything  
else it needs to
2) Fix so Release manager can use a windows system (svn 1.4.  
changed .svn format)

3) PRS
4) Smolder
5) A-Reload is pulled in as an external

Anything else ?

I seem to have the most time atm the moment, so I'll jump it for RM  
and

attempt to spear head this.


I'm still trying to find time to replicate that segfault I reported a  
few weeks ago. Should be able to get to it next week.


David

Re: Porting Bricolage to mp2: TransHandler Interference

[David E. Wheeler]

On Apr 24, 2008, at 02:20, Torsten Foertsch wrote:


Well, I think I can shed some light on that mystery. When you use
the perl-script handler instead of modperl then your C-level  
response
handler is modperl_response_handler_cgi (see src/modules/perl/ 
mod_perl.c).
This function calls modperl_env_request_populate (see modperl_env.c)  
and that
calls ap_add_cgi_vars (see httpd.../server/util_script.c). All that  
happens

in the response phase *before* the PerlResponseHandler is called.


Well, I'm no C coder, but I get the idea. Sure enough, when I use the  
perl-script handler (as we've been doing for mod_perl 1, of course),  
I see:


Trans: /workflow/profile/desk/101/101/
Trans: /101/
Cleanup: /101/
Response: /workflow/profile/desk/101/101/
Cleanup: /workflow/profile/desk/101/101/

But when I switch to the modperl handler (which was a simple find- 
and-replace, thank you very much), I see:


Trans: /workflow/profile/desk/101/101/
Response: /workflow/profile/desk/101/101/
Cleanup: /workflow/profile/desk/101/101/

*So* much better! So already Bricolage is better running on mod_perl 2  
than on mod_perl 1. :-)


Why the subreq is not set up if your transhandler is not used I can  
only
guess. Maybe it sets $r-path_info explicitly maybe it sets $r- 
filename so
that the standard maptostorage handler sets path_info. But path_info  
is

probably empty if your transhandler is not used.


It is odd, but it does seem like the perl-script handler is doing  
something different if I've installed a TransHandler.


Further I recall a problem/bug that if the PerlCleanupHandler is the  
only
configured Perl handler for a request it is not called. But that  
does not
seem to hit you since you have a (Trans|Access)Handler at least. If  
you think
that may be the case try the threading mod_perl branch. There the  
problem is
solved (http://svn.apache.org/repos/asf/perl/modperl/branches/threading 
).

That branch still does not work with perl 5.10.


I don't think that's related, but it's good to know that there is  
ongoing work on this stuff.


Thanks a million for the detailed explanation!

Best,

David

Porting Bricolage to mp2: TransHandler Interference

[David E. Wheeler]

Howdy,

I'm busy finalizing the port of Bricolage to mod_perl2. In the  
process, I've discovered a bit of weirdness with our TransHandler. For  
certain requests, it seems to execute twice. Under mod_perl1, here's  
an example:


75947 Apache=SCALAR(0x295ed70) TransHandler start for /workflow/ 
profile/desk/101/101/
75947 Apache=SCALAR(0x295ed70) TransHandler finish for /workflow/ 
profile/desk/101/101/
75947 Apache=SCALAR(0x295ed70) AccessHandler start for /workflow/ 
profile/desk/101/101/
75947 Apache=SCALAR(0x295ed70) AccessHandler finish for /workflow/ 
profile/desk/101/101/

75947 Apache=SCALAR(0x29d6f60) TransHandler start for /101/
75947 Apache=SCALAR(0x29d6f60) TransHandler finish for /101/
75947 Apache=SCALAR(0x29d6f60) AccessHandler start for /101/
75947 Apache=SCALAR(0x29d6f60) AccessHandler finish for /101/
75947 Apache=SCALAR(0x8b5970) ResponseHandler start for /workflow/ 
profile/desk/101/101/
75947 Apache=SCALAR(0x8b5970) ResponseHandler finish for /workflow/ 
profile/desk/101/101/
75947 Apache=SCALAR(0x299e870) CleanupHandler start for /workflow/ 
profile/desk/101/101/
75947 Apache=SCALAR(0x299e870) CleanupHandler finish for /workflow/ 
profile/desk/101/101/


The first number is the process number. I've just added print  
statements to each of our handlers, one at the start and one at the  
end. Note how there is this strange interim request for /101/ that the  
TransHandler and the AccessHandler handle. I've no idea where that  
comes from or what it's for. But the request finishes fine under  
mod_perl1: the ResponseHandler creates the response, and the  
CleanupHandler disconnects the session.


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/


Note how the CleanupHandler runs on the /101/ request *before* the  
response handler handles the original request URI. This leads to  
errors, since the CleanupHandler syncs the cache and disconnects it --  
so that here it's not available to the response handler! Without the  
session, Bricolage gets pretty severe heartburn. So I'm again  
wondering WTF that /101/ request is about, and why it's screwing with  
our session. Note that this is a single request, all handled by a  
single Apache process (using prefork).


When I disable the TransHandler, I get this instead:

75793 Apache2::RequestRec=SCALAR(0x8dcf00) AccessHandler start for / 
workflow/profile/desk/101/101/
75793 Apache2::RequestRec=SCALAR(0x8dcf00) AccessHandler finish for / 
workflow/profile/desk/101/101/
75793 Apache2::RequestRec=SCALAR(0x292cd00) ResponseHandler start for / 
workflow/profile/desk/101/101/
75793 Apache2::RequestRec=SCALAR(0x292cd00) ResponseHandler finish  
for /workflow/profile/desk/101/101/
75793 Apache2::RequestRec=SCALAR(0x28757c0) CleanupHandler start for / 
workflow/profile/desk/101/101/
75793 Apache2::RequestRec=SCALAR(0x28757c0) CleanupHandler finish for / 
workflow/profile/desk/101/101/


The weird /101 request goes away, and all works as it should!

My config, FWIW, looks like this:

NameVirtualHost *:80
VirtualHost *:80
  DocumentRoot   /usr/local/bricolage/comp
  ServerName localhost
  DefaultTypetext/html; charset=utf-8
  AddDefaultCharset  utf-8
  SetHandler perl-script
  PerlResponseHandlerBric::App::Handler
  PerlAccessHandler  Bric::App::AccessHandler
  PerlCleanupHandler Bric::App::CleanupHandler
/VirtualHost

Has anyone seen something like this before? For this request, all the  
TransHandler does is return DECLINED. I get the same issues even if I  
modify it do make sure it does nothing more than return DECLINED. Is  
there some side-effect of using a TransHandler that I've just missed,  
that it forces this weird appearence of a subrequest that then pushes  
the CleanupHandler execution ahead of the ResponseHandler?


Many TIA for any insight you can provide.

Best,

David

Re: Porting Bricolage to mp2: TransHandler Interference

[David E. Wheeler]

On Apr 23, 2008, at 11:09, Geoffrey Young wrote:

cleanup handlers are just callbacks run when a memory pool goes out  
of scope.


Oh. And here I thought that they ran when the request completed.

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 :)


Any idea how that can happen? Or what that weird /101/ subrequest is  
about?



I'd try these things:

 o use a PerlLogHandler instead of a PerlCleanupHandler


But that runs before the request is returned to the user, right?


 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


Thanks, I'll give those a try, just as soon as I finish building a  
debugging perl + mod_perl + Apache system to debug another issue on  
the developers list. :-)


Thanks,

David

Re: Porting Bricolage to mp2: TransHandler Interference

[David E. Wheeler]

On Apr 23, 2008, at 11:16, Torsten Foertsch wrote:

I think the /101 request is a subrequest. Do you use path_info? This  
together
with the perl-script handler can cause a subrequest when apache  
wants to
translate PATH_INFO to PATH_INFO_TRANSLATED. You can distinguish  
between a

subrequest and the main request by examining $r-main.


I was fiddling with that yesterday, and $r-main seemed to return true  
every time. But I'll try again.


Better register your cleanup handler with the request pool of the  
request you

want.


Will do, thanks.

David

Re: Porting Bricolage to mp2: TransHandler Interference

[David E. Wheeler]

On Apr 23, 2008, at 11:19, David E. Wheeler wrote:


On Apr 23, 2008, at 11:16, Torsten Foertsch wrote:

I think the /101 request is a subrequest. Do you use path_info?  
This together
with the perl-script handler can cause a subrequest when apache  
wants to
translate PATH_INFO to PATH_INFO_TRANSLATED. You can distinguish  
between a

subrequest and the main request by examining $r-main.


I was fiddling with that yesterday, and $r-main seemed to return  
true every time. But I'll try again.


The /101/ request *is* a subrequest? WTF is that coming from? It seems  
to happen after the AccessHandler finishes, but before the  
ResponseHandler runs. Maybe AccessHandler somehow triggers it? I don't  
see anything in there that looks like it calls path_info(), but I'll  
keep looking.


Best,

David

Re: Porting Bricolage to mp2: TransHandler Interference

[David E. Wheeler]

On Apr 23, 2008, at 11:53, David E. Wheeler wrote:

I was fiddling with that yesterday, and $r-main seemed to return  
true every time. But I'll try again.


The /101/ request *is* a subrequest? WTF is that coming from? It  
seems to happen after the AccessHandler finishes, but before the  
ResponseHandler runs. Maybe AccessHandler somehow triggers it? I  
don't see anything in there that looks like it calls path_info(),  
but I'll keep looking


The creation of the subrequest is weird. There code in Bricolage that  
uses path_info() (it runs on Mason after all), but I can't see why the  
subrequest gets created *only* if there is a TransHandler, even if  
that TransHandler does nothing but return DECLINED.


To whit, I changed the TransHandler to just use  
Apache2::Const::DECLINED for its handler. Nothing else. The request  
looks like this:


77532 AccessHandler   start for (main) /workflow/profile/desk/101/101/
77532 AccessHandler   finish for (main) /workflow/profile/desk/101/101/
77532 CleanupHandler  start for (sub) /101/
77532 ResponseHandler start for (main) /workflow/profile/desk/101/101/
77532 ResponseHandler finish for (main) /workflow/profile/desk/101/101/
77532 CleanupHandler  start for (main) /workflow/profile/desk/101/101/
77532 CleanupHandler  finish for (main) /workflow/profile/desk/101/101/

If I remove the TransHandler altogether, it looks like this:

77709 AccessHandler start for (main) /workflow/profile/desk/101/101/
77709 AccessHandler finish for (main) /workflow/profile/desk/101/101/
77709 ResponseHandler start for (main) /workflow/profile/desk/101/101/
77709 ResponseHandler finish for (main) /workflow/profile/desk/101/101/
77709 CleanupHandler start for (main) /workflow/profile/desk/101/101/
77709 CleanupHandler finish for (main) /workflow/profile/desk/101/101/

No subrequest appears at all! So this leads me to conclude one of two  
things. Either


1. Internally, mod_perl's TransHandler code triggers the subrequest.  
Why it would, I have no idea, but if there is no TransHandler, that  
code doesn't execute and there is no subrequest. Or:


2. There is some code executing somewhere in Bricolage between the  
AccessHander and the ResponseHandler, but only if there is a  
TransHandler. If this is the case, I have no idea where that code  
would be. Remember, this is my httpd.conf:


NameVirtualHost *:80
VirtualHost *:80
 DocumentRoot   /usr/local/bricolage/comp
 ServerName localhost
 DefaultTypetext/html; charset=utf-8
 AddDefaultCharset  utf-8
 SetHandler perl-script
 PerlResponseHandlerBric::App::Handler
 PerlAccessHandler  Bric::App::AccessHandler
 PerlCleanupHandler Bric::App::CleanupHandler
 PerlTransHandler   Apache2::Const::DECLINE
/VirtualHost

So, with this information, I can at least work around the problem by  
declining to do anything in the AccessHandler or the CleanupHandler  
when $r-main returns something, but I'm still mystfied as to where  
this subrequest is coming from.


Thanks,

David

Re: Temporary Handler?

[David E. Wheeler]

On Sep 6, 2006, at 18:19, Philip M. Gollucci wrote:


Also see:
./hooks/TestHooks/push_handlers_same_phase.pm

Its the closest test we have -- maybe extend or duplicate and tweak  
to test this and provide an example ?


Maybe something like this?

Index: t/hooks/TestHooks/push_handlers_same_phase.pm
===
--- t/hooks/TestHooks/push_handlers_same_phase.pm   (revision 105875)
+++ t/hooks/TestHooks/push_handlers_same_phase.pm   (working copy)
@@ -24,8 +24,14 @@
 my $counter = $r-notes-get('counter') || 0;
 $r-notes-set(counter = $counter+1);
+ok ! $r-get_handlers('PerlResponseHandler'),
+'There should not yet be a PerlResponseHandler';
+
 $r-push_handlers(PerlResponseHandler = \real_response);
+ok $r-get_handlers('PerlResponseHandler'),
+'Not there should be a PerlResponseHandler';
+
 return Apache::DECLINED;
}


Then just have whatever test script sends the request send it twice.

But I was asking about mod_perl1, actually. :-)

Best,

David

Re: Temporary Handler?

[David E. Wheeler]

On Sep 6, 2006, at 18:14, Geoffrey Young wrote:


yeah, that's what $r-push_handlers() does... or ought to do :)

but since you're asking yet know the answer, I'm assuming you've  
found a

bug?


No, it just makes sense to me, but is not documented that way any  
place that I can find…


Thanks,

David

Re: A::SL - Devel::Cover using httpd/mp 1.x series

[David E. Wheeler]

On Aug 25, 2006, at 02:28, Philip M. Gollucci wrote:


I promised David Wheeler this earlier today.


Oh, fine, just blame me. ;-)

Actually, what I thought you said was essentially patches welcome.  
But this works, too.


Cheers,

David

Re: Protecting source code

[David E. Wheeler]

On Aug 25, 2006, at 09:58, Jonathan Vanasco wrote:


at that point, i realized two things:

	a- encrypting/obfuscating perl code just doesn't work when you  
need to decrypt it.  it also doesn't work when there are  
decompilers and stuff out there.  the best you can do is make  
something marginally difficult.
	b- given the ease in decrypting the code, and the code itself, it  
became pretty obvious that they weren't trying to protect the code,  
as much as they were making it unreadable as it was some of the  
worst stuff i've ever seen.


Great story!

Cheers,

David

Re: Protecting source code

[David E. Wheeler]

On Aug 25, 2006, at 11:05, Octavian Rasnita wrote:


Hi americans :-)


Heh. Nailed me. ;-)

So the programmer works for the source code, makes it open source,  
and then
comes another programmer that gets it, delete the name of the  
author, make

some changes, and then sell the program pretending it is his code, and
sometimes the second programmer has more relations and can contact  
more
clients. In USA there are ways of protections, but in other  
countries there

are not.


This issue is inherent in all open source software, of course, not  
just Perl software.



I think that if mod_perl programs could be very well encrypted, this
technology would be a little more used than it is now, but they  
can't, and

if this is a disadvantage for some of us, we shouldn't say that the
programmers shouldn't need such a thing.


I think that if obfuscating the source code (by compiling or  
encrypting or whatever) is a high priority for you, then Perl may not  
be the best choice of language for your software. And even for Java  
there are decompilers and for PHP the code must be unencrypted to  
run. So maybe C is the best choice.


But you should know that there are no perfect solutions to this  
issue. Ultimately, it's a social and political issue, not a  
technological issue.


Best,

David

Re: [RELEASE CANDIDATE] libapreq 1.33 (mp1)

[David E . Wheeler]

On Dec 12, 2004, at 1:04 PM, Stas Bekman wrote:
Please test this package: http://apache.org/~stas/libapreq-1.33.tar.gz
(Apache::Request for mod_perl 1.x) and report any problems here.
All tests pass for me on Mac OS X, both with my custom install of 
Apache and with Apple's.

Regards,
David
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html