Re: Error with apache with mod_perl
On Mon, 30 Jul 2001, Mauricio Amorim wrote: Hi, my name is Mauricio 2) I install mod_perl 1.1.26 with the following options: cd mod_perl_1.1.26 perl Makefile.PL APACHE_SRC=../apache.1.3.20/src USE_APACI=1 USE_DSO=1 you should have seen this warning: Your Perl is uselargefiles enabled, but Apache is not, suggestions: *) Rebuild mod_perl with Makefile.PL PERL_USELARGEFILES=0 *) Rebuild Apache with CFLAGS=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 *) Rebuild Perl with Configure -Uuselargefiles *) Let mod_perl build Apache (USE_DSO=1 instead of USE_APXS=1) try the first option.
Re: Can't load mod_perl in Solaris 8
On Fri, 13 Jul 2001, Jie Gao wrote: This is different from what I have been hearing for the past few years: Solaris' malloc is better than perl's. you're right, i just found this in the 5.6.1 announcement: :On some systems (IRIX and Solaris among them) the system malloc is :demonstrably better. While the defaults haven't been changed in order to :retain binary compatibility with earlier releases, you may be better off :building perl with Configure -Uusemymalloc ... as discussed in the :INSTALL file. that's good news, to bad it isn't the default, sure would save alot of trouble. i will change the Makefile.PL verbage.
Re: [patch] a more user friendly server failure report
On Sat, 30 Jun 2001, Stas Bekman wrote:
As we see at the list, sometimes users have a problem to start the server
in the 'make test' stage and when they see:
server failed to start! (please examine t/logs/error_log)
many times this log file doesn't exist. So let's check whether the file
exists before we suggest to look at this file. In case it doesn't exist we
should point to the debug resource. Since currently we don't have any
final SUPPORT doc, I wrote some blurb. later on we can replace with a
pointer to a doc that explains what to do.
looks good. don't forget:
if () {
}
else {
}
not
if () {
} else {
}
this would be fine too:
my log_file_info = -e $log ?
please examine $log :
$log wasn't created, start the server in debug mode;
Re: Mod Perl 1.26, ApacheSSL and Apache 1.3.20
On Thu, 12 Jul 2001, The Doctor wrote: Why is this going on? you forgot to post your perl -V and Makefile.PL options
Re: Can't load mod_perl in Solaris 8
On Thu, 12 Jul 2001, Javier Chicharro wrote: I've compiled mod_perl-1.26 (and I tried with 1.25 too) for Apache 1.3.20 in a Solaris 8. When I start apache I get this error : you forgot to post your perl -V and Makefile.PL options
Re: having problems getting started with mod_perl
On Wed, 11 Jul 2001, Bruce Kleinman wrote: I'm a mod_perl newbie trying to get my first installation working, and I'm hitting a brick wall. I can get Apache to come up, but as soon as I try to access it, just using the machine and port as the URL, I get a core dump. make test doesn't work at all, the server never even comes up. Hope you can give me some pointers, I'm completely at a loss here. Makefile.PL should have warned, you need to give mod_perl's Makefile.PL the PERL_USELARGEFILES=0 flag or rebuild perl with Configure -des -Uuselargefiles
Re: Can't load mod_perl in Solaris 8
On Thu, 12 Jul 2001, Javier Chicharro wrote: perl Makefile.PL APACHE_SRC=../apache_1.3.20/src DO_HTTPD=1 USE_APACI=1 your original post had an error trying to load /opt/apache/libexec/libperl.so, but these options are for a static build. do you have an old modperl dso configured?
Re: Can't load mod_perl in Solaris 8
On Thu, 12 Jul 2001, Ged Haywood wrote: Hi again, On Thu, 12 Jul 2001, Javier Chicharro wrote: Yes, I compiled my Perl using Solaris cc. Is there any reason you don't want to compile static? is there any reason he should? the only issue using dso with solaris (and any other Perls that default to using Perl's malloc) is that perl needs to be built with 'Configure -des -Ubincompat5005'
Re: can't start apache-1.3.20 with mod_perl and Mason
On Wed, 11 Jul 2001, Louis-David Mitterrand wrote: Will I have to build a debugging-enabled libperl to get relevant information? Or is this enough to understand the problem? libperld would help, all i can tell is that something in %SIG is being caught, which normally shouldn't happen at startup. are you assigning anything to %SIG ? you could also try this to get the perl filename:line where the segv happens: (gdb) source mod_perl-x.xx/.gdbinit (gdb) curinfo
Re: Error in PerlRun
On Mon, 9 Jul 2001, Surat Singh Bhati wrote:
Hi,
I am not able to run the mod_perl scriptsd as with
Apache::PerlRun, Apache::Registry is working fine.
PerlRun says :
filename not found or unable to stat
and gives the 404 error.
The file is exists there with proper permission, I am able to run same
file with Apache::Registry
I changed the PerlRun.pm as:
-35 if (-r $r-finfo -s _) {
+35 if (-r $filename -s _) {
hmm, not sure why it isn't working, but this isn't the first problem
reported with $r-finfo. i think i will apply your patch, the finfo
feature clearly isn't as stable as it should be.
Re: APXS make problems with mod_perl 1.26
On Wed, 11 Jul 2001, Neil Mansilla wrote: I've successfully performed the same APXS make with mod_perl 1.25 and 1.25_01, but it breaks with the following error with 1.26: perl Makefile.PL USE_APXS=1 \ WITH_APXS=/usr/local/apache_1.3.20/bin/apxs \ PERL_STACKED_HANDLERS=1 PERL_USELARGEFILES=0 [standard Makefile.PL output is fine...] that works just fine here, however.. make[1]: Entering directory `/usr/src/mod_perl-1.26/Apache' cc -c -I../ -I/usr/local/apache_1.3.20/include -I/usr/local/apache_1.3.20/include -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\1.27\ -DXS_VERSION=\1.27\ -fpic -I/usr/local/lib/perl5/5.6.0/i686-linux/CORE Apache.c Apache.xs:51: mod_perl.h: No such file or directory Apache.xs:52: mod_perl_xs.h: No such file or directory Apache.xs:292: parse error .. i had exactly the same error when i first tried, in a mod_perl-1.26 directory i had earlier built with other options, including DYNAMIC=1 the new build tried to compile the old Apache/Apache.c did you happen to try another build in that tree prior?
Re: PerlInitHandler and PerlSetEnv
On Tue, 10 Jul 2001, Gerald Richter wrote: The docs says: SetEnv directive Syntax: SetEnv variable value Context: server config, virtual host Status: Base Module: mod_env Compatibility: SetEnv is only available in Apache 1.1 and later. Sets an environment variable, which is then passed on to CGI scripts and SSI pages. Example: There is no directory, .htaccess in the context and that's like it really behaves. (unless they changed it in a very recent version and didn't update the docs, which I don't expect) PerlSetEnv is the only chance to have different values in different directories. i think the docs are out-of-date, seems to work inside location: --- t/conf/httpd.conf~ Mon Jul 9 20:23:10 2001 +++ t/conf/httpd.conf Tue Jul 10 08:35:03 2001 @@ -160,6 +160,7 @@ /Location Location /perl/perl-status +SetEnv mod_env location PerlSetVar StatusOptionsAll On SetHandler perl-script PerlHandler +Apache::Status % GET 'http://localhost:8529/perl/perl-status?env' | grep mod_env mod_env = location
RE: announce: mod_perl-1.25_01
On Tue, 10 Jul 2001, Christian Gilmore wrote: Hrm. Ok, I'll have to release new versions of my modules that have tests for mod_perl 1.26. At what release level do you expect this patch to be committed? well, i don't want to make any promises like i did for 1.26 :)
Re: Possible bug with ModPerl 1.25 and Escape_uri
On Fri, 6 Jul 2001, Stef Telford wrote: Hello, I hope this is the right place to put this. I have some code that takes data from a database and encrypts it via Blowfish and CBC. Not a problem so far, the problems comes with sending it to the client. ... Now, if i look at the string (and ignoring all the strange characters that slip through escape_uri) i cant help but notice that escape_uri 'breaks' on the character after %99G which, lo and behold, is %00 which says to me that for some reason CGI::Cookie does the 'right thing' in the case of Blowfish encrypted text, but escape_uri in mod_perl doesnt. looks like apache's uri escape code does not properly handle binary data. one solution would be base64 encode your $ciphertext before using it to create the cookie, then decode it after fetching the cookie. you can use MIME::Base64 for this, which is fairly lightweight.
Re: upgrading mod_perl/CGI.pm shows some weirdness
On 6 Jul 2001, Peter Rooney wrote: machine 1: CGI.pm version 2.46 machine 2 (the new machine): CGI.pm version 3.02 3.02 is alpha, the README says: Version 3 of CGI.pm is in alpha state. It has significant performance improvements over the 2.X series, but is not stable. If you find a bug, please track it down, fix it, and send me the patch. i would send lincoln and report and stick with the 2.xx version for production.
Re: send_httpd_headers
On Sun, 8 Jul 2001, Brooklyn Linux Solutions CEO wrote:
Is there a way to know that headers have already been sent
before send headers out?
you can check for things that should be empty until send_http_header is
called, e.g.
unless ($r-header_in('Content-type')) {
#header has not been sent
}
unless ($r-status_line) {
#header has not been sent
}
Re: can't start apache-1.3.20 with mod_perl and Mason
On Mon, 9 Jul 2001, Louis-David Mitterrand wrote: Hi, After upgrading my installation to Apache-1.3.20 and mod_perl-1.25 as as a module I can't start apache anymore when httpd.conf contains: PerlRequire /etc/apache/perl/handler.pl And that file (for debugging purposes) is practically empty: #!/usr/bin/perl package HTML::Mason; use strict; use HTML::Mason; use HTML::Mason::ApacheHandler; 1; Running strace apache -X shows: read(3, ETE PATCH PROPPATCH MKCOL COPY M..., 4096) = 4096 read(3, mLog directive (see below).\n#\nLo..., 4096) = 4096 read(3, n /icons/uuencoded.gif .uu\nA..., 4096) = 4096 read(3, tweak mime.types without actual..., 4096) = 4096 --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ see mod_perl-1.25/SUPPORT for hints on howto get a stacktrace.
Re: send_httpd_headers
On Tue, 10 Jul 2001, Doug MacEachern wrote:
unless ($r-header_in('Content-type')) {
i meant header_out, not header_in
Re: Knowing the current VirtualHost at server startup
On Tue, 10 Jul 2001, Robin Berjon wrote:
Hi,
I've been looking around for a way for a Perl section (or code called from
it, or perhaps even loaded through PerlModule) to know the current
VirtualHost in which it is, at server startup (ie without a request object
handy).
Apache-server returns the main server object (or so it seems, that would
appear to be logical) and I know that I can use $s-next to get a chain of
server objects, but I can't seem to find a way in C or in Perl to know about
the current server.
Apache-server will point to the current VirtualHost with this patch..
--- src/modules/perl/perl_config.c 2001/06/19 03:12:45 1.110
+++ src/modules/perl/perl_config.c 2001/07/11 02:46:32
@@ -1744,7 +1744,15 @@
ENTER_SAFE(parms-server, parms-pool);
MP_TRACE_g(mod_perl_dump_opmask());
-perl_eval_sv(code, G_DISCARD);
+
+{
+SV *server_sv = perl_get_sv(Apache::__SERVER, FALSE);
+IV ptr = SvIVX(SvRV(server_sv));
+SvIVX(SvRV(server_sv)) = (IV)parms-server;
+perl_eval_sv(code, G_DISCARD);
+SvIVX(SvRV(server_sv)) = (IV)ptr;
+}
+
LEAVE_SAFE;
{
Re: duplicate libperl.so causes problems on Tru64
On Tue, 10 Jul 2001, Dave Hill wrote: Hi, I am using mod_perl-1.25_01 on Tru64 unix with apxs. The default packaging creates the DSO mod_perl as libperl.so. This causes problems on Tru64 unix as the loader cannot differentiate between libperl.so which is part of the PERL distribution and libperl.so which is the Apache DSO. I found the replacing libperl in apaci/Makefile with mod_perl (4 places) solved this issue. Given that Apache seems to use mod_*.so for library names. why not with mod_perl ? If that does not make sense, how about adding a variable that could e used with Makefile.PL ? mainly historical reasons. mod_perl followed the mod_proxy convention of nameing multi-source-file modules libname.a, which php does as well, probably others too. at the time the lib$name had to match the $name_module structure for apache's build system to get things right. the name stuck when dso was introduced. you can always rename modperl's libperl.so to libmodperl.so or whatever. 2.0 uses that name to avoid this confict/confusion and also allows you to name it whatever you like with a Makefile.PL option. i'd be happy to have a Makefile.PL option for 1.xx if you want to submit a patch, but the default will probably stay libperl.so for 1.xx.
Re: help about ap_pool in Perl
On Tue, 10 Jul 2001, Alberto Canzi wrote: Hi I need to use the ap_pool structure. In my Apache Module writing book is explained how to use it in C but nothing is said about using it in Perl. How does it work ? How may I use it in Perl? what do you need to use it for from Perl? much of the Perl api uses ap_pool underneath, and certain functions are exposed, such as register_cleanup, but normally you shouldn't need to use it directly from Perl.
Re: swapping of mod_perl parent process / mlockall()
On Tue, 26 Jun 2001, Adi Fairbank wrote: Is it correct that when the Apache/mod_perl parent process swaps to disk, a large part of it (swapped pages) becomes unshared? Even after the kernel restores the pages from swap, do they remain unshared? So once the parent process becomes unshared, new apache children that are spawned only share the parent's pages that have never been swapped? This is what I've grok'ed from my experiments with top/GTop. If this is the case, it would be helpful to prevent the parent process from *ever* swapping to disk. The Linux kernel has a system call mlockall() which disables all memory paging for the current process. This sounds like exactly the recipe for preventing parent process swapping. It won't affect spawned child processes, so shouldn't pose a threat of consuming all physical memory and crashing the system. I want to play around with this, but I'm not sure where in the mod_perl source to call mlockall(). It would need to be before the parent spawns any children.. Has anyone tried using Linux's mlockall()/mlock() with mod_perl? according the manpage: Child processes do not inherit page locks across a fork. so you would need to call it in a child init handler, but: Only root processes are allowed to lock pages.
Re: push_handlers and PerlAuthenHandler troubles [second try]
On Tue, 26 Jun 2001, Bolt Thrower wrote:
My apologies if you've seen this twice.
For a particular Location, I'd like to selectively (i.e., based on
arbitrary criteria) determine whether a visitor needs authentication.
So I set up a Location section in httpd.conf as follows:
PerlAuthenHandler Intranet::CheckSiteAuthen
#PerlAuthenHandler Apache::AuthTicket-authenticate
package Intranet::CheckSiteAuthen;
...
sub handler {
my $r = shift;
$r-warn(starting CheckSiteAuthen);
$r-push_handlers(PerlAuthenHandler =
'Apache::AuthTicket-authenticate');
in the current sources, you cannot push a handler in the current
phase. you could use a PerlAccessHandler to push the PerlAuthenHandler
instead.
Re: announce: mod_perl-1.25_01
On Sat, 7 Jul 2001, Stas Bekman wrote: On Fri, 6 Jul 2001, Doug MacEachern wrote: all tests pass cleanly. cool. under bleed-perl (one week old compilation) (the rest is the same) there are some problems: (perl build args are at the end of this post) $ ./t/TEST -v modules/cgi fails to start the server, whereas 1.xx never did start the server like that, its a 2.0 only feature. $ make start_httpd cp t/conf/mod_perl_srm.conf t/conf/srm.conf ../apache_1.3.20/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...\c done (it reports 'done' even if it's failed to start the server, because there was another server running already on the same port. try to run 'make start_httpd' twice in a row and you will see) $ more t/logs/error_log [Sat Jul 7 20:55:01 2001] [crit] (98)Address already in use: make_sock: could not bind to port 8529 same problem if you 'make test' and there's already a server running. has always been this way. 2.0 however, first tests that the port is available before attempting to start the server. reason: [Sat Jul 7 20:57:02 2001] [error] (13)Permission denied: exec of /usr/src/httpd_perl/mod_perl-1.25_01/t/net/perl/cgi.pl failed [Sat Jul 7 20:57:02 2001] [error] [client 127.0.0.1] Premature end of script headers: /usr/src/httpd_perl/mod_perl-1.25_01/t/net/perl/cgi.pl this only happens when running this test standalone or also during full 'make test' ? is it setup to use the correct perl? % head -1 t/net/perl/cgi.pl build warnings: ... mod_perl.c:333: warning: unused variable `my_perl' these have also been here as long as ithreads, left as a reminder, 1.xx should be optimized for ithreads.
Re: PerlInitHandler and PerlSetEnv
this patch should fix the problem. you should also be able to
s/PerlSetEnv/SetEnv/g, unless Embperl needs these variables before the
fixup phase.
Index: src/modules/perl/mod_perl.c
===
RCS file: /home/cvs/modperl/src/modules/perl/mod_perl.c,v
retrieving revision 1.140
diff -u -r1.140 mod_perl.c
--- src/modules/perl/mod_perl.c 2001/06/19 03:12:44 1.140
+++ src/modules/perl/mod_perl.c 2001/07/10 03:19:27
@@ -1388,6 +1388,14 @@
cfg-setup_env = 0; /* just once per-request */
}
+if (cfg-dir_env != cld-env) {
+/* PerlSetEnv
+ * update only if the table changes across a request
+ */
+mod_perl_dir_env(r, cld);
+cfg-dir_env = cld-env;
+}
+
if(callbacks_this_request++ 0) return;
if (!r-main) {
@@ -1397,9 +1405,6 @@
*/
(void)perl_request_rec(r);
}
-
-/* PerlSetEnv */
-mod_perl_dir_env(r, cld);
/* SetEnv PERL5LIB */
if (!MP_INCPUSH(cld)) {
Index: src/modules/perl/mod_perl.h
===
RCS file: /home/cvs/modperl/src/modules/perl/mod_perl.h,v
retrieving revision 1.109
diff -u -r1.109 mod_perl.h
--- src/modules/perl/mod_perl.h 2001/06/19 03:12:45 1.109
+++ src/modules/perl/mod_perl.h 2001/07/10 03:19:30
@@ -1064,6 +1064,7 @@
typedef struct {
HV *pnotes;
int setup_env;
+table *dir_env;
array_header *sigsave;
} perl_request_config;
Re: announce: mod_perl-1.25_01
On Mon, 9 Jul 2001, Christian Gilmore wrote: Doug, I didn't see in the announcement that the below fix is included in 1.25_01. Can you please confirm? the patch has not been committed and will probably wait until after 1.26. i'm concerned that the current patch might introduce bugs elsewhere, its a thorny problem to solve and i don't want to delay 1.26 any longer.
Re: Accessing server config during parent startup
On Mon, 9 Jul 2001, Robin Berjon wrote: cfg = (axkit_dir_config *) ap_get_module_config(s-module_config, XS_AxKit); try s-lookup_defaults instead of s-module_config see also: modperl-2.0/src/modules/perl/modperl_pcw.c where you can see howto access all of the config apache has parsed. the same logic should work with 1.x, just need to s/apr_pool_t/pool/g and the like.
Re: RFC: Logging used Perl Modules (was Re: API Design Question)
On Tue, 3 Jul 2001, James G Smith wrote:
The current code I have uses %INC, but I wanted to write
something like the following:
sub use : immediate {
# do stuff here if logging
return CORE::use(@_);
}
you could just override CORE::GLOBAL::require. you don't need to
override the import, and your version of require will be called at the
same time as the 'use'.
RE: modperl install without Apache src?
On Sun, 8 Jul 2001, Ged Haywood wrote: Hi there, On Fri, 6 Jul 2001, Knox, Laurie A, NPONS wrote: I read somewhere that there were potential problems when running mod_perl and PHP together in Apache, but I haven't been able to find that info again Is this an issue? I fear it is. Lots of people seem to run into trouble with that combination, I think Doug is looking at it again right now. i was looking into something related to directive handlers, and last time i looked, the problem was not specific to php. and of course, not a problem unless you're using directive handlers. the only other known problems i know of are: - older php's did not pickup largefile flags from apxs, which is fixed now if you use current 4.0.something - php ships with its own mysql client, if you're using DBD::mysql, you need to build php with configure --with-mysql=..., where ... is you system mysql directory.
Re: PerlInitHandler and PerlSetEnv
On Tue, 10 Jul 2001, Gerald Richter wrote: Yes, this fixes the problem :-) cool. Embperl doesn't need them before the fixup phase, but sometimes you want different values for the environment variables for different directories, which doesn't work with SetEnv really? glancing at mod_env.c looks like it should work. Thanks for the fast fix would have been sooner but i was on an airplane the past 6 hours :)
Re: announce: mod_perl-1.25_01
On Fri, 6 Jul 2001, Ken Williams wrote: [EMAIL PROTECTED] (Doug MacEachern) wrote: this is a 1.26 canidate, test reports most appreciated as always.. I just tested on Darwin (Mac OS X) with Apache 1.3.20 and using a simple 'perl Makefile.PL EVERYTHING=1' . All tests pass, with no warnings emitted during compilation. I think this is the first time that's happened for me on Darwin. =) great news!
RE: cvs commit: modperl-2.0/Apache-Test/lib/Apache TestConfigPerl.pm
On Mon, 9 Jul 2001, Geoffrey Young wrote:
die in modperl_startup.pl if modperl_{inc,extra}.pl die
anyway, I thought modperl_extra.pl was supposed to be optional?
it is still optional, but if it exists and dies, then mod_perl should
propagate that. although, the $@ !~ /^Can.t locate/ is bogus, because it
might be that modperl_extra.pl was located, but a module it requires was
not.
Re: modperl install without Apache src?
On Fri, 6 Jul 2001, Ged Haywood wrote: Hi there, On Thu, 5 Jul 2001, Knox, Laurie A, NPONS wrote: I was going to upgrade it to 1.25, but I don't have the Apache src. Why don't you just get it? there should be no need if apache was properly installed with a header tree. mod_perl can be built as a dso without the apache source tree, with the Makefile.PL USE_APXS,WITH_APXS options.
Re: apache won't start, strange dynaloader problem...
On Thu, 28 Jun 2001, Jim Woodgate wrote: [Thu Jun 28 16:04:01 2001] [error] Can't load '/usr/contrib/lib/perl5/site_perl/5.6.1/i686-linux/auto/Apache/Request/Request.so' for module Apache::Request: libapreq.so.0: cannot load shared object ^ file: No such file or directory at /usr/contrib/lib/perl5/5.6.1/i686-linux/DynaLoader.pm line 206. Request.so is there but where is libapreq.so.0 ?
Re: BUG PATCH (was: Strange status returns from perl_handler)
On Wed, 23 May 2001, Julian Gilbey wrote: On Mon, May 21, 2001 at 06:36:54PM +0100, Julian Gilbey wrote: We've just upgraded a SunOS machine from Apache 1.3.9 + mod_perl 1.21 (dynamically linked) to Apache 1.3.19 + mod_perl 1.25 (statically linked). I have a CGI/Perl script, handled as normal by perl-script and Apache::Registry. Now, this CGI script sometimes returns a page with status something like '403 Forbidden', including full content and full headers. With the old version, the perl_handler function returned with status=0 (OK), even if the HTTP status was going to be 403, and then Apache was quite happy with this. However, in the current combination, the perl_handler function returns with the HTTP status, so that the Apache core adds on its own content. can you post an example script? i think the current sources do the right thing. re-reading your message, it sounds like you should be using a CustomResponse (or $r-custom_response) if you want to generate a 403 response yourself. i realize what you're doing 'worked' in older mod_perls, but that was a bug, not a feature.
Re: Requests using If-Modified-Since cause response Set-Cookie tobe discarded
On 21 Jun 2001, Randal L. Schwartz wrote: Uh, it seems a bit fishy to me. nothing's changed, but by the way, set this cookie please. Why change a cookie if nothing else has changed? don't gimme this 'fishy' mumbo jumbo, i'm willing to accept a valid reason why set-cookie shouldn't be included in a 304 response, but i have yet to hear one. let me restate some facts from the thread, quoting rfc 1945: 304 Not Modified If the client has performed a conditional GET request and access is allowed, but the document has not been modified since the date and time specified in the If-Modified-Since field, the server must respond with this status code and not send an Entity-Body to the client. Header fields contained in the response should only include information which is relevant to cache managers or which may have changed independently of the entity's Last-Modified date. Examples of relevant header fields include: Date, Server, and Expires. A cache should update its cached entity to reflect any new field values given in the 304 response. in andrew's case it sounds like set-cookie falls into here: or which may have changed independently of the entity's Last-Modified date quoting his email: The cookie records, in part, the time of the last access to the site. Therefore for each access the cookie is updated. that to me sounds like a header which may have changed independently of the entity's Last-Modified date. the client stores cached files in a different place than cookies, so set-cookie is not going to invalidate a cached file.
RE: Solaris mod_perl DSO...
On 22 Jun 2001, Jay Thorne wrote: Hmm. I've tried this on perl 5.5.x and 1.25 on a linux box, and I still get the 4meg leak per HUP hi, for the nth time, 5.005 leaks, 5.6.1 does not.
Re: Requests using If-Modified-Since cause response Set-Cookie tobe discarded
On Wed, 20 Jun 2001, Nenad Steric wrote: Hi, Thanks for your answer, saved me days of probably fruitless fidling around with modperl. Your solution solved my problems (see Sending Cookies on Page-Reload) the question remains if this violates some RFC's (or breaks some browsers), and if there is some other way - like faking that the file-date has changed. (i am not quite confortable with patching every new apache version again, or would it be a good idea to send this to the apache-guys ?) i passed it along the same day: http://hypermail.linklord.com/new-httpd/2001/Jun/0507.html still awaiting response on my interpretation of the rfc, seems perfectly valid to include the set-cookie header with a 304 response. you could of course delete the if-modified-since header from headers_in, but that would put an end to caching of those documents, something i'm sure nobody wants todo.
RE: Solaris mod_perl DSO...
On Thu, 21 Jun 2001, Paul G. Weiss wrote: I've done it with 5.6.1. There was a fairly detailed thread on it last week on how it was done. In order to avoid a memory leak on restart you need to build with a bleed modperl though. If you can start and stop your server you're fine with 1.25. as you pointed out before, you can configure: PerlSetEnv PERL_DESTRUCT_LEVEL 2 without installing cvs modperl.
Re: Apache::Cookie-fetch fails silently
On Fri, 15 Jun 2001, Rodney Broom wrote: I've got this handler that calls Apache::Cookie-fetch, no problem. It's tested and works fine. So I installed the same handler (same machine) on a second Apache instance, but now Apache::Cookie-fetch fails, causing the handler to terminate. No messages, no nothin'. It doesn't even get to the next print() statement after the fetch() call. try Apache::Cookie-new($r)-parse; Apache::Cookie-fetch uses the global request_rec which might not be setup yet, depending on what phase you're in. you could also set it up yourself first: Apache-request($r); Apache::Cookie-fetch;
Re: Setting an auth realm dynamically
On Fri, 15 Jun 2001, Rodney Broom wrote:
I (like everybody else) have a site that is wholy dynamically
generated. As such, I can't alway set an auth realm in the config or in
.htaccess. What I'd like to do is an access handler like this:
sub handler {
my $r = shift;
if ($r-uri =~ m/$some_magic_pattern/|) {
$r-auth_name($custom_realm);
$r-auth_type('Basic');
those two should work.
$r-dir_config('require valid-user');
this will not. $r-requires could be made writable, but i worry about
getting used to that since it will not work with threaded-2.0 without
changes to apache.
Re: Requests using If-Modified-Since cause response Set-Cookie tobe discarded
On Mon, 18 Jun 2001, Andrew Gilmartin wrote: I have PerlAuthenHandler handler that sets a cookie on authentication success. The cookie records, in part, the time of the last access to the site. Therefore for each access the cookie is updated. When a new document is accessed or a CGI script is run the cookie is sent to the browser. However, if the browser is asking for a document it has cached it will send an If-Modified-Since header. The file delivery mechanism in Apache will do the right thing with If-Modified-Since information and only send the document if, in fact, it has changed. Unfortunately, if it has not changed the cookie I set in my handler is discarded (no matter if I use $r-header_out() or $r-err_header_out()). How can I force Apache to send the Set-Cookie header even if the document being delivered has not changed? I suspect that I am not the first person to run into this problem. A search of the list was unsuccessful, unfortunately. i've not tested, but it looks like Set-Cookie is left out on purpose (maybe an http rfc compliance thing or just a bug), this patch might help.. --- src/main/http_protocol.c~ Tue Apr 17 11:30:14 2001 +++ src/main/http_protocol.cTue Jun 19 09:46:29 2001 @@ -2637,6 +2637,7 @@ Warning, WWW-Authenticate, Proxy-Authenticate, +Set-Cookie, NULL); terminate_header(r-connection-client);
RE: Confusion resolved (was: mod_perl DSO leaking on restart)
On Tue, 19 Jun 2001, Christian Gilmore wrote: Doug, Will this patch make it into 1.26? yes. If so, is there a slated release date for 1.26? soon-ish. you can always configure: PerlSetEnv PERL_DESTRUCT_LEVEL 2 in the meantime.
Re: Confusion resolved (was: mod_perl DSO leaking on restart)
On 19 Jun 2001, Vivek Khera wrote: Drat. Not here. I just sucked down the latest mod_perl CVS with this patch, and I still lose 9M per USR1... Lemme try some tracing to see what gives here. (FreeBSD 4.3, perl 5.005_03) i mentioned earlier in the thread 5.005_03 has leaks. although, with the t/ config (make start_httpd_fork), i see ~140k of leakage per USR1, compared to 9M is a surprise, but i suppose the 5.005_03 leakage depends on what you have loaded.
Re: [Patch] Apache-dso_module()
On Mon, 18 Jun 2001, Philippe M . Chiasson wrote: In my case, I used it to work around the strange mod_perl behaviour under DSO (fixed in CVS) right, so that is no longer needed. any other examples? i hesitate on adding the feature because anything that needs to be conditional based on mod_perl being a dso probably means that there is a bug in mod_perl that should be fixed instead. Sure, only question, is the .so extension generic enough ? How about on Win platforms ? win32 recently started using .so for all apache dso modules.
Re: Install mod_perl on Solaris 2.7
On Mon, 18 Jun 2001, Paul Lindner wrote: -Uusemymalloc \ ... PERL_CCEOPTS=-Dccflags='-DPERL_EMERGENCY_SBRK -DTWO_POT_OPTIMIZE -DPACK_MALLOC' these options are only in effect when using Perl's malloc, which -Uusemymalloc turns off. they are also all turned on by default in 5.6.0+
Re: Install mod_perl on Solaris 2.7
On Mon, 18 Jun 2001, Paul Reynolds wrote: What versoin of mod_perl are you using? I tend to stay away from 1.25. care to share the problems you have with 1.25? if they are not fixed in cvs, now is the time to make them known to be fixed for 1.26.
Re: Confusion resolved (was: mod_perl DSO leaking on restart)
ah ha, right, since i always have PERL_DEBUG=1, perl_destruct_level is
always set to 2. good find! it should always be 2 for dso, this patch
seems to fix USE_APXS too.
--- src/modules/perl/mod_perl.c 2001/06/14 04:49:08 1.137
+++ src/modules/perl/mod_perl.c 2001/06/19 01:59:18
@@ -259,8 +259,6 @@
if((pdl = getenv(PERL_DESTRUCT_LEVEL)))
perl_destruct_level = atoi(pdl);
-else
- perl_destruct_level = PERL_DESTRUCT_LEVEL;
if(perl_destruct_level 0) {
MP_TRACE_g(fprintf(stderr,
@@ -510,6 +508,7 @@
array_header *librefs;
librefs = xs_dl_librefs((pool *)data);
+perl_destruct_level = 2;
perl_shutdown(NULL, NULL);
unload_xs_so(librefs);
}
Re: Apache::StatINC patch
thanks, this has been applied for 1.26-tobe. On Wed, 14 Mar 2001, Ilya Konstantinov wrote: Hi, While developing with mod_perl and Apache::ASP here at Aduva SID department, we've came across an annoying problem. Apache::ASP adds it's 'Global' directory to @INC. We naturally used it to store modules. Since mod_perl resets @INC across requests but doesn't reset %INC, Apache::StatINC sometimes found changes in the used modules, but couldn't reload them (since their directory wasn't in @INC). This patch will insert missing directories into @INC on the fly.
Re: untraceable uninit warnings
On Wed, 7 Mar 2001, Graham Barr wrote:
Does anyone have any idea what could be causing
Use of uninitialized value at PerlHandler subroutine `VC::Delivery::Cycle::handler'
line 1.
to appear in the errorlog ?
I even added
local $SIG{__WARN__} = sub { warn here };
as the first line of VC::Delivery::Cycle::handler, but it never gets
triggered, so it would seem the uninit is before the sub is called.
The strange thing is that it is only this one handler that causes
such a warning, all others are fine.
this will only happen if you gave Makefile.PL PERL_MARK_WHERE=1
which will modify CopFILEGV(curcop) if Perl doesn't know what it is for
some reason. not sure why the WARN hook is being ignored, if you can
whittle it down to a small test case i will have a look.
Re: Problem with $r-register_cleanup()
On Wed, 7 Feb 2001 [EMAIL PROTECTED] wrote:
Hi,
I just ran into a problem with $r-register_cleanup() only sometime beeing
called.
This is mod_perl 1.24_01, perl 5.6.0, apache 1.3.14 compiled with gcc 5.6.0 on
AIX 4.3.3.
Here's a sample code (snippet):
sub handler { # PerlTransHandler
my $r = shift;
$r-register_cleanup(\clean1);
$r-push_handlers(PerlCleanupHandler = \clean2);
$r-pnotes('cleanup', bless {} );
print STDERR 'in ;
^ ^
could this have something todo with it?
after fixing that, i tried your transhandler and get the expected results
in the error_log:
in register_cleanup register_cleanup push_handlers push_handlers DESTROY
if you still see this behavior with 1.25, i'd need more info of how to
reproduce the problem, such as what requests you're making that produce
unexpected results.
Re: BSDI 4.1 libperl.so problem
On Thu, 8 Feb 2001, Aaron Schlesinger wrote: Hi there. I am having a HELL of a time trying to get mod_perl compiled into apache 1_3.17. I built it using APXS and I really have tried everything I can think of. It makes, and builds without a problem. When I try to do a configtest (after installing the new LoadModule and such into the httpd.conf file) I get this: % apachectl configtest Syntax error on line 207 of /usr/local/apache/conf/httpd.conf: Cannot load /usr/local/apache/libexec/libperl.so into server: File not found the problem is likely that the dynamic linker cannot find a shared library that was linked against modperl's libperl.so. you can find out by using bsdi's equivalent of strace or truss (to trace system calls) and look for failed calls of open() for .so files.
Re: CONNECT proxy rewrite
On Thu, 1 Mar 2001, Chris Lewis wrote:
Does anybody know how to alter the destination of a CONNECT transaction
(in this case secure proxy request) in mod_perl?
$r-uri(newplace:newport) in a Trans handler doesn't seem to do it.
mod_proxy uses the parsed_uri, try this:
use Apache::URI ();
$r-parsed_uri-hostname('newplace');
$r-parsed_uri-port('newport');
$r-uri('newplace:newport');
Re: /dev/null problems
On 28 Mar 2001, Matthew Kennedy wrote: Hello, From the mod_perl guide: syntax error at /dev/null line 1, near line arguments: Execution of /dev/null aborted due to compilation errors. parse: Undefined error: 0 There is a chance that your /dev/null device is broken. Try: % sudo echo /dev/null This is exactly the problem I have been getting when starting Apache mod_perl, however the suggested fix does not work for me. We're on a HPUX 11 machine. Is there another way to solve this problem? As I understand it, if /dev/null is being used as the $0 argument to the handler, perhaps I could somehow explicitly set it to another (empty) file? How would I go about that? you can use this patch. -e0 used to be the default, but caused some problems related to suexec or something. --- src/modules/perl/mod_perl.c~Wed Jun 13 22:17:51 2001 +++ src/modules/perl/mod_perl.c Thu Jun 14 10:02:15 2001 @@ -670,7 +670,7 @@ #ifdef WIN32 argv[argc++] = nul; #else -argv[argc++] = /dev/null; +argv[argc++] = -e0; #endif MP_TRACE_g(fprintf(stderr, perl_parse args: ));
Re: ChildInitHandler
On 30 Mar 2001, Nikolaus Rath wrote:
Hello!
The following code doesn't work. I think that child_init_handler is
never called. But there are no errors in the error log.
sub child_init_handler($$)
{
my($this,$r) = @_;
$r-log_error(Session Manager initialized);
return OK;
}
sub child_exit_handler($$)
{
my($this,$r) = @_;
$r-log_error(Session Manager initialized);
^^^
maybe you were expecting a different error message?
PerlChildInitHandler Apache::foo-child_init_handler()
PerlChildExitHandler Apache::foo-child_exit_handler()
^^
need to loose the parens, you should get an error for that. i tried your
code, works fine, startup:
[Thu Jun 14 10:08:42 2001] [error] Session Manager initialized
kill -HUP:
[Thu Jun 14 10:08:43 2001] [error] Session Manager stopped
Re: mod_perl DSO leaking on restart?
On Wed, 25 Apr 2001, Philip Mak wrote: On Thu, 26 Apr 2001, Stas Bekman wrote: There is also the strange case of mod_perl leaking memory on graceful restarts when compiled as DSO. But I don't feel like getting into this one quite yet. Hmm. My httpd was using 20 MB. I did apachectl graceful ten times, and the usage jumped to 24 MB. Then I did apachectl graceful another ten times, and the usage jumped to 29 MB. I guess that's the reason (or one of them) that my httpd grows bigger and bigger as time passes. My mod_perl is a DSO (I run two copies of httpd, one without mod_perl and one with; I set it up as a DSO since this way I only need one executable). Should I recompile it statically linked? repeat 1.21_01 had two dso fixes, one to close all .so's opened by DynaLoader and one to call perl_shutdown(), both of which were large leaks. with 1.25_01-dev and Perl 5.6.1 i see a 4k growth on the first kill -USR1 and no change after that. what is your perl -V and mod_perl version? /repeat if people are seeing leaks on restart using Perl 5.005_03 i am not surprised, 5.6.1 plugs a great many leaks.
Re: Tracking down taint problems
On Tue, 24 Apr 2001, Jamie Krasnoo wrote: I recently got this error: Insecure dependency in eval while running with -T switch. Callback called exit. Now, yes that tells me that something is wrong. What it doesn't tell me is where the problem is except for the fact that its somewhere in the current module that's being run. Is there a way that I could get mod_perl to fess up where the problem is? if you can reproduce at will, use gdb: % gdb httpd (gdb) source mod_perl-x.xx/.gdbinit (gdb) b Perl_croak (gdb) run -X ... run request that causes error ... (gdb) where ... stack printed here ... (gdb) curinfo ... perl filename:linenumber printed here ...
Re: crash on exit with -X
On Wed, 9 May 2001, Greg Wilson wrote: Hi. We're getting a segfault when httpd shuts down when using mod_perl on Red Hat 6.2, and I'd like to know whether anyone else has seen this as well. If I run httpd -X -f /home/gvwilson/httpd.conf under gdb, the stack trace is: can you rebuild mod_perl with Makefile.PL PERL_DEBUG=1 ... then set the MOD_PERL_TRACE enviornment variable to 'g' and post the output of: % grep 0x error_log which should show us the .so's modperl is trying to close.
Re: Build problem (lperl)
On Sun, 15 Apr 2001, Sean LeBlanc wrote: I'm trying to have mod_perl build apache during its own build, but I'm getting an error that I can't dig any answers up on. I have the libperl.so.5.6.0 in /usr/lib, but I'm uncertain how to get compiler to recognize that it is there. I ran ldconfig, but still no luck. % ln -s libperl.so.5.6.0 libperl.so but you shouldn't need todo that and your libperl should not be in /usr/lib -L/usr/lib/perl/5.6.0/CORE this looks broken, there should be an architecture component to the path. your perl -V might shed some light.
Re: sending a response without a Content-Type header
On Mon, 16 Apr 2001, Matthew Darwin wrote: I'm buiding an HTTP gateway in mod_perl and trying to send back to the client exactly what I get from the remote server. The remote server doesn't set a Content-Type on the document being returned, so I don't want to set one either. However, Mod_perl (or Apache), doesn't like it when I don't send a Content-type and seems to send a default of text/plain regardless. I don't want this. I don't want any Content-type at all. What I have now is sending mod_perl a Content-Type of ''. This sends a blank Content-Type to the browser. How can I avoid doing this? ... $r-send_http_header; roll your own version of send_http_header. apache's send_http_header will always send a content-type, part of being rfc compliant i guess.
Re: Trying to trace a spinning httpd
On 7 May 2001, Yusuf Goolamabbas wrote: Apache 1.3.19/Mod-perl 1.25 under Linux 2.2.19 Hi, I am trying to better understand Apache/mod-perl behaviour under this scenario. I have some CGI's which connect to various servers listening on different ports and collect the output and push them to the clients. Whilst the data is streaming from the server to the CGI, I kill the server. After a few seconds, I see httpd take up increasing amount of CPU time [it can go up to 90% of CPU]. straceing the httpd process shows that it is continuously in a read call to the file descriptor representing the connection it was last in I ran httpd in single instance mode [httpd -X] and attached gdb to it. I sourced .gdbinit and typed curinfo This is what I get (gdb) curinfo Attempt to extract a component of a value that is not a structure pointer. what is your perl -V? you might need to move up the stack first: (gdb) up 7 (gdb) curinfo #8 0x80e574b in Perl_pp_readline () this would be the operator, did you check the return value from whatever you use to connect to the socket ? what are you using to connect to these various servers?
Re: mod_perl DSO leaking on restart?
On Thu, 14 Jun 2001, Paul G. Weiss wrote: Sad to say, I'm not as fortunate as you. I'm leaking ~4.4Mb which each HUP (I haven't tried USR1). I'm also using Perl 5.6.1 and 1.25_01-dev (the CVS snapshot modperl_20010614113010.tar.gz). I'm doing a PerlRequire if that is significant. One more thing - I'm building mod_perl using apxs. I don't know if that makes a difference. i am surprised to see, it does make a difference. i built with: perl Makefile.PL USE_DSO=1 EVERYTHING=1 - no leaks. perl Makefile.PL USE_APXS=1 WITH_APXS=... EVERYTHING=1 - leaks. i haven't looked into it yet. can you try with USE_DSO=1 ? if you're still leaking please post your 'perl -V' and the full list of Makefile.PL options you're using.
Re: Getting unbuffered output from a subprocess
On Tue, 27 Mar 2001, Andrew Ho wrote: Hello, So, when doing a CGI and needing to execute a subprocess with input based on user input, I always do a open()-fork()-exec() like so: ... When using a mod_perl script, I use Apache::SubProcess and the above stuff still works. However, let's say the subprocess I kicked off takes a while to process, but prints status information in the meantime (for example, tagging a big CVS tree, or indexing textfiles, or whatnot). I want the user to see the information real-time (so I'd probably have local $| = 1 inside the if($pid) block above). This no longer works under Apache::SubProcess. Tt buffers up all the output and then sends it all at once. So my parent process reads in an unbuffered way, but the child exec() outputs all at once. can you post a small test case using Apache::SubProcess? that'll make it easier to see whats going on.
RE: Tracking down taint problems
On Thu, 14 Jun 2001, Rob Bloodgood wrote: Seriously, tho, do you think you could come up with a short list of definitions for those macros? I was pretty excited to see them, once, except that I couldn't make them work. sigh Even a comment w/ a usage: AvFILL(address) most of them (the C macros) are documented in Perl's perlapi.pod the gdb macros are just the cpp expanded versions of the C macros, not including some of the homebrewed ones like curinfo.
Re: Finding AuthUserFile name with the request object.
On Sat, 5 May 2001, Rodney Broom wrote: Hi all, I'm trying to add a little bit more security to a running app. In this app, I'd like to be able to confirm what physical file was used in the 'AuthUserFile /path/to/pass.db' statement. This file choice needs to be dynamic, so I can't simply hard wire this info. this has been asked a bunch of times in the past and normally i say mod_auth's structures are private to mod_auth.c, which is still true, but the structure is small and unlikely to change for 1.3.x, we can just copy-n-paste it. so here's a little module to access AuthUserFile, AuthGroupFile and AuthAuthoritative config, see the mod_auth_example script for usage: http://perl.apache.org/~dougm/Apache-ModAuthConfig-0.01.tar.gz
RE: NameWithVirtualHost
On Thu, 17 May 2001, Geoffrey Young wrote: well, you're not using Apache::Registry (which uses the $Apache::Registry::NameWithVirtualHost global) but Apache::RegistryNG (for which there's no corresponding $Apache::RegistryNG::NameWithVirtualHost :) he used Apache::RegistryNG in the startup.pl, but we didn't see httpd.conf, which i'm guessing is configured to use Apache::Registry, because.. I haven't used RegistryNG at all, so I don't know the benefits of it over Registry (someone might) but I suspect that you will get the namespace isolation you desire if you move to Apache::Registry instead. Apache::RegistryNG actually uses $r-filename instead of $r-uri so it should have namespace protection.
Re: Getting the wrong URL
On 1 Jun 2001, [EMAIL PROTECTED] wrote: OK, I think I have solved this problem, but I would like to run my solution by you folks, and see if it makes any sense. What we found, on a more thorough code review, was that a number of the handlers were doing a redirect by calling send_cgi_header, and then exit()'ing. It seemed to us that the exit would kill the Perl interp, and the Apache child would then just keep serving whatever it had in its buffer at the time. Does that make any sense? If so, will die() have the same results? I started grepping for exit everywhere, and removed it, but along the way I saw a number of places that we're calling die. i'm missing the original message, but if you can post a small test case, along with results and expected results, we can look into it.
Re: PerlSetEnv scoping (again)
i will add this to the ToDo to look at before 1.26. in the meantime, if you don't need to access these variables before the fixup stage and don't need %ENV to be inherited by a forked program, try changing PerlSetEnv to SetEnv. On Sat, 2 Jun 2001, Roman Maeder wrote: back in 1998 and 99 there was a longer discussion about scoping problems with PerlSetEnv (inside httpd.conf and .htaccess files), which ended with fixes applied to mod_perl-1.20, which is the version I have been using (along with apache-1.3.6 and perl 5.00404) Now I am setting up a brand new machine to replace my aging web server and compiled Perl 5.6.1, apache_1.3.20, and mod_perl-1.25 (Solaris 8) and the old problem is back, only worse. This is so severe I can't imagine it happening in all configurations out there, but here is what I found. Summary: 1 a variable defined with PerlSetEnv in the main server (outside any virtual hosts) cannot be changed inside a virtual host section (the change is ignored) 2 a variable defined inside a virtual host section is visible to all *other* virtual hosts and the main server 3 a variable defined in httpd.conf cannot be changed inside a .htaccess file (the change is ignored) I set up my Apache with a minimal httpd.conf and two IP-based virtual hosts (besides the main server), configured like this (plus the necessary AllowOverride All, etc.; see attached file) # main server DocumentRoot /www/test/root PerlSetEnv VarA Global PerlSetEnv VarB Global # virthost 1 VirtualHost IP1 DocumentRoot /www/test/root1 PerlSetEnv VarA VirtHost1 PerlSetEnv VarC VirtHost1 /VirtualHost # virthost 2 VirtualHost IP2 DocumentRoot /www/test/root2 PerlSetEnv VarA VirtHost2 /VirtualHost additionally, /www/test/root2 contains this .htaccess file PerlSetEnv VarB root2 PerlSetEnv VarD root2 Using a Apache::Registry script to print the enviroment in all three servers (main and the two virtual hosts), I get these values Var mainvirthost1 virthost2 VarA Global Global* Global* VarB Global Global Global* VarC VirtHost1* VirtHost1 VirtHost1* VarD - - root2 the entries with the * are wrong, I think. Has anyone seen something like this before? Regards, Roman Maeder
Re: errors installing Apache 1.3.19/mod_perl 1.25 on RedHat 6.1
On Tue, 10 Apr 2001, Jonathan Swartz wrote: % ./configure --activate-module=src/modules/perl/libperl.a ... %Config is not exported by the Apache::ExtUtils module at -e line 0 this is a bug. newer mod_perl's override %Config::Config using Apache::ExtUtils, which when you build inside the mod_perl-1.xx tree is found ok, but inside the apache tree the build is picking up your older Apache::ExtUtils. you can bandaid by setting the PERL5LIB environment variable inside the apache_1.3.19 tree to: `pwd`/../mod_perl-1.25/lib
Re: Resetting STDIN after r-read
On Fri, 8 Jun 2001, Rodney Broom wrote:
OK, here's what the solution was. According to Doug in a posting that I
found in an archive search, mod_perl's STDIN is really just a Perl glob, and
not a file handle. So instead of reading from it (and thereby emptying the
file handle named STDIN so that CGI and other things can't get this data),
now I simply assign from it:
*{STDIN} is a Perl glob. STDIN is a Perl IO 'handle', which is normally
used to access C's stdio stdin FILE pointer. under mod_perl, the STDIN
handle is tied to the Apache request_rec, rather than stdio stdin.
i never said anything about using the $STDIN scalar. $STDIN is just like
any other global variable, except that it aliased to $main::STDIN no
matter what package you reference it from. $STDIN != STDIN
if ($first_pass) {
print TEMP_FILE, $STDIN;
this will only work if you first read(STDIN, $STDIN, $content_length);
otherwise, you're getting the global value from the previous request,
since $STDIN is not reset. and again is no different from using a global
such as $Foo::PostData, other than the aliasing mentioned above.
Re: Make Test problems...
On Sun, 10 Jun 2001, Ian (the webguy) wrote: ... I'm not sure what's causing this. When I telnet to port 8529 and try to get /test.html, I get snip !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN HTMLHEAD TITLE403 Forbidden/TITLE this is a bug in the test suite, permissions problem if you 'make' as root. if you can 'perl Makefile.PL ... make' as another user and 'make install' as root the test should work fine.
Re: mod_perl DSO leaking on restart?
On Fri, 15 Jun 2001, Paul G. Weiss wrote: alignbytes=8, usemymalloc=y, prototype=define ^ ok, here's why i kept asking for perl -V. i don't see Perl's malloc.c ever release its memory pool. when usemymalloc=y, free() only puts memory back into Perl's pool for use by other malloc()'s. i don't see a function to destroy this pool when perl cleans itself up. willing to bet if you rebuild Perl with: Configure -des -Uusemymalloc ... and then rebuild mod_perl, the leaks will go away.
Re: DSO mod_perl HUP memory leak
On Thu, 14 Jun 2001, Paul G. Weiss wrote: I know that this is an ongoing problem, but I seem to remember that someone somewhere had a patch that reduced the size of the memory leak on restarts to a manageable size. Has this patch been applied to the CVS version? If not, can some kind soul tell me where to find it? I've looked around the net in vain. 1.21_01 had two dso fixes, one to close all .so's opened by DynaLoader and one to call perl_shutdown(), both of which were large leaks. with 1.25_01-dev and Perl 5.6.1 i see a 4k growth on the first kill -USR1 and no change after that. what is your perl -V and mod_perl version?
Re: [Patch] Apache-dso_module()
On Fri, 25 May 2001, Philippe M . Chiasson wrote:
I know I posted this patch a while ago, but I am looking thru a few patches
I have and I thought I might re-post this one along with the rest
This module allows one to do
Apache-dso_module('module_name.c') and it will be true only of the
module in question is present and has been loaded as DSO.
Used to be usefull to me when attempting to work around Perl directives
and mod_perl as DSO/not-DSO (now fixed).
But I figured it could be usefull to others.
any examples you can think of? in any case, it would be better to have
Apache-module('mod_foo.so') provide this functionality rather than add a
new method.
Re: [Patch] apxs location forgotten in MyConfig.pm
On Fri, 25 May 2001, Philippe M . Chiasson wrote: When building mod_perl with apxs as a DSO, MyConfig.pm looses track of the location of apxs. Therefore, when using 3rd parties perl modules that require some access to Apache information, like Apache::src-new-inc, it will most likely fail, unless apxs happens to be in a 'standard' location or in your PATH. applied, thanks.
Re: [Patch] perl Makefile.PL PREFIX=/foo/bar breakage
On Fri, 25 May 2001, Philippe M . Chiasson wrote: When passing a PREFIX=/foo/bar to Makefile.PL, all the perl .pm will get installed under /foo/bar/lib/site_perl/perl-version/perl-arch but mod_perl.so isn't aware of that. So, mod_perl will refuse to start, failing to locate Apache.pm. My first way around this was to PerlRequire a file before anything else and push /foo/bar/lib/site_perl/perl-version/perl-arch on the @INC path, but it's not very elegant. This patches automatically makes sure the PREFIX path, if specified, is placed first in the @INC path. nice work, applied.
Re: BUG PATCH (was: Strange status returns from perl_handler)
On Wed, 23 May 2001, Julian Gilbey wrote: Right, here's a patch. This line of code was erroneously removed some time between version 1.21 and 1.25 of mod_perl. see Changes: fix bug where Apache::send_http_header was resetting r-status = 200 thanks to brian d foy for the spot the problem is that setting r-status = 200 makes for bogus access_log entries. (2) After this, it is used to record the status of the Perl script. The perl_call_handler function in mod_perl.c takes a status value of 200 to mean that everything has gone OK. perl_call_handler doesn't check r-status, it checks the return value of the subroutine. using r-status is hack for Apache::Registry, which i guess has not quite been untangled. i will revisit the problem before 1.26 and see if we can fix both the response problem and maintain proper access_log entries. thanks for the patch, i know this particular problem is painful, been there a couple of times already :(
Re: segfault on subrequest?
On Thu, 15 Mar 2001, Pierre Phaneuf wrote:
I have a PerlTransHandler that is very simple:
the problem is likely that your trans handler is recursing. try adding
this to prevent recursion:
sub handler {
my($r) = @_;
return unless $r-is_main;
my($info);
$info = $r-lookup_file('/home/pp/pierre.jpg')-content_type();
warn(content type is $info\n);
return DECLINED;
}
But it causes a segfault when invoked... I removed the
-content_type(), so that I should normally see something like
Apache::SubRequest=SCALAR(0x815eb54), but it also crashes.
I tried using the exact same handler as a PerlHandler and as a
PerlHeaderParserHandler instead, and it works perfectly. I was thinking
that calling lookup_uri from within a PerlTransHandler might be a bad
idea (infinite loops!), but I would have thought that lookup_file would
be ok...
Okay, maybe everyone will jump in my face about this: this is on an
updated Red Hat 7.0 system, using Red Hat's Apache and mod_perl RPM
packages.
Re: Segfault on ppc-linux with modperl-1.25 with Apache 1.3.19 whencalling $r-send_fd()
On 19 Mar 2001, Mark Lipscombe wrote:
open ($FH, $fname);
...
$r-send_fd($FH);
you didn't check the return value of open(); patch below will check if
the filehandle is NULL and croak rather than segfault.
Index: src/modules/perl/Apache.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/Apache.xs,v
retrieving revision 1.122
diff -u -r1.122 Apache.xs
--- src/modules/perl/Apache.xs 2001/06/14 04:36:21 1.122
+++ src/modules/perl/Apache.xs 2001/06/14 05:24:25
@@ -956,6 +956,10 @@
long length
CODE:
+if (!f) {
+croak(send_fd: NULL filehandle
+ (hint: did you check the return value of open?));
+}
RETVAL = send_fd_length(f, r, length);
OUTPUT:
Re: Efficient pre-loading of symlinks and virtual directories
On Thu, 29 Mar 2001, Stas Bekman wrote: The latest policy is mod_perl-1.3 doesn't accept any new features and provides only bug fixes. All the development goes into 2.0. i think you mean mod_perl-1.xx :) and, its Apache::Registry that doesn't accept new features. Apache::RegistryNG and Apache::PerlRun do, unless it is something that can be provided with a subclass. new features are still accepted for mod_perl-1.xx, but some will be punted into 2.0 land. Still you can subclass Apache::PerlRun and provide your own method for the unique namespace package generation. right. would be cool to see a version of this on cpan that uses the inode stuff. and this feature can be considered as an option for 2.0's Apache::Registry.
Re: accessing SSL environment data in Perl*Handler
On Wed, 4 Apr 2001, Paul wrote:
Though I feel rather foolish, the fact remains that I can't seem to
find my SSL environment variables.
httpd.conf has
Directory /
SSLVerifyClient require
SSLOptions+StdEnvVars
# ...
/Directory
Exactly when and where are they set? For example, SSL_CLIENT_S_DN. Once
set, shouldn't I be able to just say $ENV{SSL_CLIENT_S_DN}?
My PerlPostReadRequestHandler can't seem to see them, but I figure
that's just because they haven't been set yet. I can't find when
they're set anywhere in the docs. (I probably haven't looked in the
right place, but it's not for lack of trying. =o)
mod_ssl doesn't setup its variables until the fixup stage, you need to run
a subrequest to get at them eariler. the auth chapter at www.modperl.com
has a specific example.
Re: installating mod_perl-1.25/apache_1.3.19/perl 5.005_02/solaris5.6
On 10 May 2001, qazi Ahmed wrote: gcc -O -I/usr/local/lib/perl5/sun4-solaris/5.004/CORE -I/usr/local/inusr/local/lib/perl5/sun4-solaris/5.004/CORE -I../../os/unix -I../../i/../apaci` -c Apache.c perl /usr/local/lib/perl5/ExtUtils/xsubpp -nolinenumbers -typemap /us Usage: xsubpp [-v] [-C++] [-except] [-prototypes] [-noversioncheck] [ this is a somewhat recent change. xsubpp with 5.004_04 coredumps processing Apache.xs, adding -nolinenumbers was the solution. you can try removing -nolinenumbers from the src/modules/perl/Makefile
Re: can not redirect on POST w/ CGI.pm
On Wed, 13 Jun 2001, David Young wrote: I've found that if I post to this PerlAccessHandler, I get no response: ... mod_perl/1.24 this problem is fixed in 1.25, from Changes: fix $r-read() so it will not block if all data has already been read and so that Apache will not hang during ap_discard_request_body() on error or redirect after all data has been read
Re: credit card processing
On Wed, 23 May 2001, Adam Prime wrote: I was looking through the mod_perl archives and saw a post from doug about a credit card processing system called 'creditor' i looked on the covalent web site, but i couldn't find any info. Did this thing ever see the light of day? yes, credator (product spells with an 'a' rather than 'i') is part of the 'commerce server' bundle: http://www.covalent.net/products/commerce/
Re: Cutting down on the DEBUG bloat...
On Tue, 10 Apr 2001, Paul Lindner wrote:
Hi,
As part of my ongoing effort to streamline my mod_perl apps, I've come
to discover the joy of constant subroutines and perl's ability to
inline or eliminate code at compile time. I have a solution that
works, but would be interested in seeing if others had better
syntactic sugar.. Anyway:
We have a module CP::Util, with this begin block:
BEGIN {
$ENV{CP_DEBUG} ||= 0;
if ($ENV{CP_DEBUG} == 1) {
*{CP::Util::DBG} = sub () {1;};
} else {
*{CP::Util::DBG} = sub () {0;};
}
}
@EXPORT_OK = qw(DBG);
Then, in another module I do:
use CP::Util qw(DBG);
DBG debug('whoa there boy');
The end result is, when CP_DEBUG=1, the code is in there. When
CP_DEBUG=0, the code is trimmed out at compile time (because DBG is a
constant subroutine, see perldoc perlsub for more info)
This is a real win compared to our old way of using a subroutine
called debug that did a no-op. Consider:
debug 'whoa there' . $foo . join(keys(%bar));
The args to debug are still computed, passed on the stack, etc..
Now, my question is: Is there some trick I could use to retain the simple syntax:
debug foo bar;
it is possible, and has been on the optimizations slide for the 2.0
talks i've been giving. one idea i had in mind was:
$r-log-debug(...);
would be nulled out unless LogLevel is configured to debug.
i have fiddled with it, you can try this:
http://perl.apache.org/~dougm/condsub-0.01.tar.gz
see test.pl for the examples.
i'm open to names/interface changes, the module is just a
proof-of-concept.
Re: modify Server header via a handler
On Wed, 2 May 2001, Matt Sergeant wrote: Right, but the problem is you can't do this after module initialization (which is where mod_perl adds it's bits), but the PerlModule's are loaded after that time, so you can't do it from Perl, at least not without a major re-design of the mod_perl internals. You can't even do it from XS loaded from Perl, because of that reason. wha? major re-design?? PerlModules are loaded during module init. with this patch, i can call this from startup.pl: Apache::add_version_component(Foo/1.1); % HEAD http://localhost:8529/ 200 OK Connection: close Date: Tue, 08 May 2001 15:13:12 GMT Server: Apache/1.3.20-dev (Unix) mod_perl/1.25_01-dev Perl/v5.7.1 Foo/1.1 Content-Type: text/html Client-Date: Tue, 08 May 2001 15:13:12 GMT Client-Peer: 127.0.0.1:8529 --- src/modules/perl/Apache.xs~ Tue May 8 08:03:23 2001 +++ src/modules/perl/Apache.xs Tue May 8 08:09:31 2001 @@ -371,6 +371,13 @@ BOOT: items = items; /*avoid warning*/ +void +add_version_component(name) +const char *name + +CODE: +ap_add_version_component(name); + const char * current_callback(r) Apache r
Re: [phil@fifi.org: Bug#85328: New method $req-allowed() forlibapache-mod-perl]
On Fri, 9 Feb 2001, Daniel Jacobowitz wrote: [please maintain the CC's] I just received the following bug report on the Debian bug tracking system. The patch seems to apply to 1.25; is it a good idea? thanks, applied to cvs for 1.26-tobe. (and sorry for the delay)
Re: [PATCH] [phil@fifi.org: Bug#86964: One more method ( patch)for libapache-mod-perl]
On Sun, 4 Mar 2001, Daniel Jacobowitz wrote: Here's another reasonable-looking patch from Philippe Troin; it exposes child_num() in Apache::Connection. i hesitate adding this to Connection.xs at this point since it is 1.3 specific. but i would be happy to include it as an new method Apache::Scoreboard. --- Scoreboard.xs~ Mon Jun 5 11:58:01 2000 +++ Scoreboard.xs Tue May 1 11:10:24 2001 @@ -392,3 +392,15 @@ OUTPUT: RETVAL + +MODULE = Apache::Scoreboard PACKAGE = Apache::Connection + +int +child_num(conn) +Apache::Connection conn + +CODE: +RETVAL = conn-child_num; + +OUTPUT: +RETVAL
Re: Much Todo about nothing
On Fri, 27 Apr 2001, Paul Cotter wrote: If this is the wrong place to post then please advise [EMAIL PROTECTED] is the place for 2.0 FYI: At http://perl.apache.org/from-cvs/modperl-2.0/ when extracting modperl-2.0_20010427110246.tar.gz there is a file called Todo and a directory called todo. This is a 'problem' in a windows environment which is case insensitive. Obviously easy to bypass. thanks for the report, fixed.
Re: Is mod_perl on win32 possible??
On Fri, 27 Apr 2001, Gunther Birznieks wrote: But someone has to care enough to put the work into it. If you care enough, you can contribute your time to making this happen. :) if anybody wants to invest time in this, it must be done in 2.0. the framework is already there for multithreaded support, which will also work for win32. it just needs a build mechanism.
Re: an unusual [job request] + taking mod_perl to the commercialworld
On Sat, 28 Apr 2001, Stas Bekman wrote: Hey, we have a product -- mod_perl. All we need is to nicely pack it, start selling it, support it and put the money back into mod_perl RD. Covalent does this already. all of the bundle products include mod_perl, and anybody can buy support packages where support for mod_perl is covered. Covalent also puts a great deal of resources back into mod_perl RD (me :) not to say it couldn't be taken a few steps further, bundling a Perl distribution and useful CPAN modules along with it. and of course, Covalent is the only company that can offer such a product.
Re: an unusual [job request] + taking mod_perl to the commercialworld
On Sat, 28 Apr 2001, Stas Bekman wrote: Oh, I didn't know that [Covalent sells mod_perl]. I guess that's because I'm not on the buyer side. Does it announce this fact? So why don't we have a link to Covalent from the perl.apache.org site? I think this is very essential for mod_perl to tell people that there are companies which sell mod_perl and provide a support! I think Covalent won't mind to have a such a link too. yes, i've been meaning to put a link on perl.apache.org not to say it couldn't be taken a few steps further, bundling a Perl distribution and useful CPAN modules along with it. and of course, Covalent is the only company that can offer such a product. You mean Covalent is the only company that can offer such a product now. It doesn't mean that some other company will provide a better packaging and sell it too, right? whoops, that was supposed to say 'is _not_ the only'. i will say again what i meant: and of course, Covalent is not the only company that can offer such a product.
Re: [Patch] Apache-dso_module() to find if a module is loaded asDSO or not
On Thu, 26 Apr 2001, Stas Bekman wrote:
sure, but that's a different matter. I say that PerlModule and PerlRequire
have a bug, which should be fixed. It's just that your problem made me
reiterate the problem.
patch below fixes. problem was the reference to
@Apache::ReadConfig::PerlConfig created an entry in %Apache::ReadConfig::,
which triggered perl_section_self_boot() to delete $INC{$startup_pl}
i think that using *Apache::ReadConfig elsewhere will still trigger the
double loading of all Perl{Require,Module}s, but i doubt the people
suffering from the double load problem are using that feature. so i'll
deal with that later.
True, one of the reasons why I don't use DSO. I guess Doug dedicates all
his time on 2.0, and rather not do anything else than the critical bug
fixing for 1.x. But if anybody sends a patch in, the thing will be
probably added. Doug, please correct me if I'm wrong.
i am still committed to supporting 1.xx, its just a matter of time. of
course it is much more fun working on the new stuff :)
--- Apache/Apache.pm2001/01/29 16:07:08 1.62
+++ Apache/Apache.pm2001/04/26 05:16:08
@@ -30,7 +30,10 @@
sub httpd_conf {
shift;
-push @Apache::ReadConfig::PerlConfig,
+no strict 'refs';
+#use a symbolic reference so %Apache::ReadConfig::
+#is empty at compile time
+push @{Apache::ReadConfig::PerlConfig},
map $_\n, @_;
}
Re: cvs commit: modperl/src/modules/perl mod_perl.c
On Wed, 7 Mar 2001, Ask Bjoern Hansen wrote: On 6 Oct 2000 [EMAIL PROTECTED] wrote: dougm 00/10/06 13:18:29 Modified:t/internal error.t src/modules/perl mod_perl.c Log: more for the "Apache::send_http_header was resetting r-status = 200" fix Doug, do you remember what this was about? just that sent_http_header should not modify r-status (I just had a problem with only being able to get redirects from a subrequest to work if I set status == 302 but returned 200 from the handler). you should not modify $r-status and return 302 from the handler.
sourcegarden (fwd)
-- Forwarded message -- Date: Thu, 1 Feb 2001 18:52:02 +0100 From: Emmanuel Pierre [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: sourcegarden hi doug, I have a forbidden on this site pointed by perl.apache.org http://modperl.sourcegarden.org/ Cordialement, Emmanuel PIERRE Directeur Informatique et dveloppements _ APR-Job www.jobscout24.fr - Meet your future _ HumanLine France SAS 9, rue de Lens 92000 Nanterre tel: +33 1 47 81 02 41 fax: +33 1 46 49 05 26 [EMAIL PROTECTED]
Re: Cannot make mod_perl on *@!* RH Linux :(
On Tue, 30 Jan 2001, Nick Tonkin wrote:
When I run the perl Makefile.PL command like that (without the SSL_BASE
directive) I get:
Error: Cannot find SSL header files in any of the following dirs:
Error: . /usr/include /usr/include/ssl/ /usr/local/include
/usr/local/include/ssl
So I do
find / -name ssl -print
and get:
/tmp/apache_1.3.17/src/modules/ssl
/usr/share/ssl
so I do perl Makefile.PL with SSL_BASE=/usr/share/ssl and get a different
error:
Error: Cannot find SSL binaries under /usr/share/ssl
maybe /usr/local/openssl?
i installed openssl-0.9.6 on rh7 and the default location was
/usr/local/ssl
with lib/lib{crypto,ssl}.a and include/ subdirectories
Re: Runaways
On Mon, 29 Jan 2001, Robert Landrum wrote:
I have yet to solve the runaway problem, but I came up with a way of
identifying the URLS that are causing the problems.
First, I added the following to a startup.pl script...
$SIG{'USR2'} = \apache_runaway_handler;
setting that to \Carp::confess to get a stacktrace might be more useful.
Re: Problems w/ mod_perl 1.24_01 apache 1.3.14 -- causing segmentation faults.
On Fri, 26 Jan 2001, wells wrote: I've been trying to install mod_perl 1.24_01 the following way: (with perl 5.6.0) perl Makefile.PL \ APACHE_PREFIX=/usr/local/apache \ APACHE_SRC=../apache_1.3.14/src \ DO_HTTPD=1 \ USE_APACI=1 \ EVERYTHING=1 \ APACI_ARGS='--enable-module=rewrite --enable-module=expires you might want to try 1.25 and add PERL_USELARGEFILES=0 to that list. newer php's are supposed to properly deal with uselargefiles flags, but you didn't mention your php version.
Re: Problems
On Fri, 26 Jan 2001, David I Wolf wrote: Not sure if this is the right list, but.. I'm running mod_perl on RedHat 7. I installed the new PHP updates and all of a sudden it broke mod_perl.. I get this in my error_log try 1.25 built with perl Makefile.PL PERL_USELARGEFILES=0 ...
Re: make mod_perl
On Sat, 27 Jan 2001, Ilya wrote: when I run make test I get this: cc -c -fno-strict-aliasing -I/usr/local/include -O -DVERSION=\"1.31\" -DXS_VERSION=\"1.31\" -DPIC -fpic -I/usr/local/lib/perl5/5.6.0/i386-freebsd /CORE Symbol.c Symbol.xs: In function `XS_Apache__Symbol_cv_const_sv': Symbol.xs:106: `na' undeclared (first use in this function) Symbol.xs:106: (Each undeclared identifier is reported only once Symbol.xs:106: for each function it appears in.) *** Error code 1 Stop in /root/temp/mod_perl-1.24_01/Symbol. *** Error code 1 Stop in /root/temp/mod_perl-1.24_01 any suggestions? try 1.25, which includes the change: rid PL_na usage in Symbol.xs
