Re: Memory leak on reload when the 'Pg' driver is preloaded
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 16 October 2002 20:25, Keith G. Murphy wrote: By should, do you mean that the problems with the loadable module overall are so well-known that no one in his right mind should ever use it? Yes. The problems with DSO mod_perl are well known. It works perfectly when build staticly into Apache, though. Install apache-perl package instead of apache and libapache-mod-perl. Everything works with it as it would on normal Apache. After migrating to apache-perl, remove the LoadModule for mod_perl from your Apache configuration. Might it be related to the Perl-malloc problem cited here: http://apache.perl.org/docs/1.0/guide/install.html#When_DSO_can_be_Us ed If either of the above or true, seems like Debian needs to quit distributing libapache-mod-perl. The problem is not Debian-related, so it won't justify removing the package from Debian. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9raVtnksV4Ys/z5gRAt+TAJwOZXcdnVNoLWLza7NU6eOpCOB+dQCdEliU VDvG6M+qI88/RN/jj7KsCC0= =0/Bl -END PGP SIGNATURE-
Re: Memory leak on reload when the 'Pg' driver is preloaded
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 16 October 2002 22:52, Keith G. Murphy wrote:
It's not like it was an obvious problem: I only got the DSO to leak
when loading the Pg driver. That's pretty obscure.
Have you tried to connect() without loading the Pg driver first? E.g.
$dbh = DBI-connect('dbi:Pg:dbname=foo;host=bar', 'user', 'pass');
It would help eliminate if the leak is caused by your startup script. If
it is, it may be the DBI module that's leaking memory.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9rcZ5nksV4Ys/z5gRAjBQAJwKOUuu4B14yLe1msSNekI0mnPvdACdFMOe
TFLM0arS4L177Y+OuJMAUgM=
=GsvK
-END PGP SIGNATURE-
Re: Memory leak on reload when the 'Pg' driver is preloaded
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
OK, it gets weirder. The following script produces the leak. If I
comment out the install_driver line, I get a big old segfault! Same
if I comment out the Apache::DBI line in addition. This works with
plain apache, or apache-ssl.
#!/usr/bin/perl
use strict;
use Apache::Status ();
use Apache::DBI ();
DBI-install_driver('Pg');
1; #return true value
I looked into it with the following setup:
apache 1.3.26-0woody1
libapache-mod-perl 1.27-2
postgresql 7.2.1-2woody2
There was a Test.pm module handling all requests for /. It opened a
connection to the database and fetched a couple of rows.
With DBI-install_driver('Pg'), the Apache processes stayed at 8.4 MB. I
bombarded the Apache with ApacheBench and multiple SIGUSR1 but I found
no memory leaks. The process sizes did not change.
If I comment it all out including the Apache::Status line, I get
neither the segfault or the leak. (Well, small leak, a few bytes).
Without the install_driver() in place, everything worked as well. The
Apache processes stayed at near 6 MB. No segfaults. No problems.
So the install_driver masks a bigger problem with Apache::Status?
That's just too weird. But true, I swear.
Is there anyone else out there with Debian stable w/
apache+libapache-mod-perl who can try to reproduce this simple case?
I'd really like either a confirmation or a counterexample. If the
latter, I'd chalk it up to a weirdness on my system (and probably not
even pursue it, since I've moved on to the static version). I'm
pursuing it this far so Dan J. might get some useful feedback.
I'm pretty tired at the moment, so there might have been something I
mislooked. I'll give it another look tomorrow. At work, where I don't
have any distractions :)
It's pretty odd, in my view, that the Apache processes which did not
preload the Pg driver were smaller.
Keith, could you post results to modperl list if people at debian-isp
come to a different (or to the same) solution. I'm not subscribed to
the list.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9rxEXnksV4Ys/z5gRAqlBAJ9xKgkCmCxsg8huo/C1N0uk2XKSowCgoCdr
FdyuRGCkZvDifk5fyqfOcdo=
=im3K
-END PGP SIGNATURE-
Re: use http-equiv to refresh the page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 06 November 2002 15:19, Eric L. Brine wrote: HTML 4.01 also has a section on META and http-requiv. However, the only reference to refresh is: Note. Some user agents support the use of META to refresh the current page after a specified number of seconds, with the option of replacing it by a different URI. Authors should __not__ use this technique to forward users to different pages, as this makes the page inaccessible to some users. Instead, automatic page forwarding should be done using server-side redirects. All the HTTP-EQUIV meta tags are relics from static HTML pages. The HTTP server (eg. Apache) reads meta tags from HTML pages and appends all meta tags with HTTP-EQUIV to outgoing HTTP headers. This feature is not available for dynamic content; dynamic pages must set their own headers. I'm guessing this is because http-equiv is designed to hold an HTTP header, but there is no such thing as an Refresh header in HTTP. There is a Refresh header in HTTP. It's syntax is the same as for the HTTP-EQUIV meta tag. So http-equiv=refresh is no longer standard. Of course, this is all theoretical. In practice, too many people are not easily swayed by a measily thing such as a standard. UAs are not required to deal with meta tags which contain HTTP-EQUIV content. Both Internet Explorer (at least 6, v6+ may also support them in quirk mode) and Netscape/Mozilla should interpret them if the server does not include them in the real HTTP headers. Some UAs don't do this, eg. Konqueror, and support for them might go away any time without notice, so it should not be used. The CGI module enables the programmer to add arbitrary HTTP headers with the syntax header( -type = 'text/html', -refresh = '0; url=http://www.address.com/' ); See 'perldoc CGI' for more information. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE90OTjnksV4Ys/z5gRAhTxAJ9tv49KSvNt0JRbzf2Uws+wiOIM4ACfdzDX zhojTxLkGITTQT8MkAVACIg= =fQe4 -END PGP SIGNATURE-
Re: stopping concurrent logins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 03 April 2003 20:33, Perrin Harkins wrote: Of course you could also just totally prevent people from logging in again if there is already an active session for that user, but that will cause problems because your sessions will not get invalidated if a user shuts down his browser or crashes his machine. We did just this on our secure server. My boss was worried our customers might share their login accounts (for which they had to pay), so we set up the login authentication so, that only one session could be logged in at any given time. The sessions timed out in a couple of hours, so losing the cookie would not cause permanent loss of access. We later added a button to log out other sessions, if correct user name and password was given for an already open account. After which the user had to login again. The user authentication information was stored into a cookie. The cookie was stored also on the server. Each time the user accessed the secure server, his cookie was verified against the one stored on the server (plus, of course, verifying that the cookie was valid and authorised to access whatever resource he was trying to access). If the cookie matched the one stored on the server, access was granted. If, however, the cookie did not match, the server immediately expired the user cookie and presented a login screen. If he was able to log in, the button to log out the other session would appear, but no cookie was sent to the user, meaning he would need to provide the authentication credentials again. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+jdRrWD8Ca88cV68RAh0CAKCJDGoh0hf864clmwzamz4gChmhsQCfZua1 fLXzhdGbdgzN5zd11LtSHeQ= =2/M8 -END PGP SIGNATURE-
Re: Convert Cookies--HTTP Request Headers?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Saturday 05 April 2003 00:10, Kruse, Matt wrote:
For every request to Apache:
1. Parse the cookie coming in via the request header
2. Pull out each value (ex: NAME=bob;TITLE=boss)
3. Convert them to HTTP Request Headers
4. Pass the request on to the requested resource (a script of some
sort)
You'd need to write PerlHeaderParserHandler for that.
So, if I have a cookie like: NAME=bob;TITLE=boss
My program would then see the following headers in the request:
HTTP_NAME=bob
HTTP_TITLE=boss
Why name NAME to HTTP_NAME? Or do you want the cookie content to appear
in subprocess environment (which has similar naming convention), like
other server variables?
This will help me simulate a Single-Sign-On situation where the
authentication handler passes all authenticated user information to
the resource via headers.
Can anyone help me by either:
1. Giving an outline of what handlers I would want to use, and how
I can write request headers with them
or
The header parse phase would be ideal, since you're parsing headers.
PerlInitHandler is an alias PerlHeaderParserHandler in .htaccess files.
2. Writing some sample code :)
package Your::SSOHandler;
use strict;
use Apache::Constants qw(:common);
use Apache::Cookie;
sub handler {
my $r = shift;
my $in = $r-headers_in;
return DECLINED unless $in-{'Cookie'};
my $cookies = Apache::Cookie-parse($in-{'Cookie'});
return DECLINED unless $cookies{'YourAuthenticationCookie'};
my %values = $cookies{'YourAuthenticationCookie'}-value;
my $env = $r-subprocess_env;
while (my ($key, $value) = each %values) {
my $h_key = 'HTTP_' . uc($key);
$in-{$h_key} = $value;
$env-{$h_key} = $value;
}
return OK;
}
1;
in httpd.conf (or .htaccess), put the following line where approppriate:
PerlModule Your::SSOHandler
PerlHeaderParserHandler Your::SSOHandler
Or something like that. Cutting and pasting may cause parse errors on
incompatible windowing environments :)
NOTES:
1. I'm running Apache 2.0 and mod_perl 2 right now, but I can bump
it down if required
I don't know much about the differences in mod_perl 1 vs 2. These
handlers work at least for Apache/mod_perl 1.
2. I've already used mod_headers to simulate this, but
unfortunately that isn't dynamic enough for testing, ie, I need to
change httpd.conf and re-start the server to test different header
scenarios.
For testing you could make the handler module stat and evaluate contents
of an external Perl file. Put your code on the file to be evaluated,
and avoid restarts.
Or simply sending SIGUSR1 to the Apache parent process should be enough
for it to restart child processes and reread configuration.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE+jp7eWD8Ca88cV68RAuBAAJ9u0KWd2bAsHrYes/DXtareCYi00gCgkIEC
o8OTRNmghIHRUhJZAqX+gbs=
=YCIq
-END PGP SIGNATURE-
