Philippe M. Chiasson wrote:
André Warnier wrote:
[...]
Even better is to turn the problem code into a short mod_perl test skeleton
(http://perl.apache.org/docs/2.0/user/help/help.html#Problem_Description)
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 startp.pl or similar.
I added a link in my links the web page to the startup.pl 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.
