perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: duplicate sockets ? mod-perl 2.0.2, apache 2.2
Date Sat, 15 Sep 2007 12:43:55 GMT

Philippe M. Chiasson wrote:
> André Warnier wrote:
> Even better is to turn the problem code into a short mod_perl test skeleton
> (

I tried to do that at first, but the problem appears only when I open 
the connection to the database server, and did not find an easy way to 
really simplify that part.  That portion, by the way, is offset in a 
sub(), which is only called when get_basic_auth_pw() returns a user-id.

>> I am not explicitly running this during startup, but maybe it happens 
>> without my knowledge.
>> Is a PerlAuthenHandler executed during a start/restart, even if I do not 
>> pre-load it ?
> I should not be, no. Unless you explicitely load it somewhere else, like
> in a or similar.

I added a link in my links the web page to the script I use. 
But it makes no reference whatsoever to the authentication module.

>> And if so, does it explain why I get two connections, and 
>> can I do anything about it and/or about these duplicate sockets ?
> Missing from the link you give is the relevant httpd.conf file
> that configures your module.
I also addded a link to a copy of the configuration file for that 
virtual server.  The reference to the module is at the end.
There is no other reference to this module anywhere else (not in the 
main httpd.conf file, not in other virtual servers).

> BTW, are you using a threaded MPM by any chance ?
I don't really know.  This is the vanilla version of Apache2 available 
for Linux Debian Etch.  The configuration and modules are spread out all 
over the place, and the main apache2.conf file shows several MPM 
settings, but conditional.
How do I see what MPM it is using ?
Is there some kind of httpd command-line option that would tell me which 
is the MPM used (à la perl -V) ?  (ok, I can look it up in the Apache 
doc, but maybe you know off-hand ?).

> Also, you should _really_ avoid filehandles like XMLSRV and stick with
> lexicals, like connect(my $xmlsrv, [...]) as these are more global than
> you might think.
It was so in the first version of the module (which had the same 
problem). I changed it to a "vanilla" filehandle to see if it made any 
difference.  I can change it back and test again if you wish.
I also tried to use IO::Socket:.INET instead of low-level sockets and 
other variations, but all variations have the same symptoms.
All the socket connection code (open, write, read, close) is in a sub(). 
  If I change it to avoid a filehandle and use a variable, should I use 
a lexical (my $xmlsrv), or a global (our $xmlsrv) ? Should I check if 
the variable is defined beforehand, and force a "close()" if it is ?

> Another thought. Did you realize that when a web browser visits a password
> protected area, it will have to make *2* requests ?
> First it will make a regular request, and the server will say 401, auth required.
> That's when the browser asks the user for a username/password and re-sends.
> Could that explain it ?

Yes, I understand this.  The module follows the general plan as per the 
examples in the documentation : it calls get_basic_auth_pw(), and if it 
subsequently has no user-id, returns 401 immediately.  In that case, no 
socket to the database module is ever opened (that I know of).
(I can follow this in the logfile)
If it gets a user-id/pw (at the second call), then it proceeds to check 
it against the database, and for that it needs to open the socket.
Because of the diag logging messages I put in the code, I don't see how 
it could possibly call the socket-opening code twice.
But that is of course the very reason why I am puzzled, because the 
database module logging shows it does, somehow.

View raw message