cgi_to_mod_perl manpage suggestion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I just got around to playing with mod_perl after a considerable amount of time that I'd relied on mod_Cgi. First and foremost, I really, really, really love it and would have switched much sooner had someone simply explained to me the one difference that I was unaware of until I decided to bother looking (and I think many people suffer from this): that while mod_cgi calls a wrapper to run a script, mod_perl does it internally. Once I understood that, I read up and installed it as soon as I felt I had some idea what I was doing. The move was uneventful (I just built it as a DSO and changed my ScriptAlias to a normal Alias, and added PerlHandler, SetHandler, etc). The only problem was the PerlSendHeaders option. The first fifty or so times that I read the manpages, I understood that PerlSendHeader On means that mod_perl will SEND HEADERS, and that off meant supply your own... Somehow I figured out (eventually) that this was not so, switched all of my deliberately placed PerlSendHeader Off statesments to a single On statement, and all of my scripts once again work. I think the main problem was the line : By default, mod_perl does not send any headers by itself, however, you may wish to change this: PerlSendHeader On That seems to say that if you want mod_perl to handle headers for you, cange it to On. Perhaps I'm still newbie enough that I still am missing the idea, but if I am correct, it would probably be a good idea to change (or even remove) that line from the man-page. Issac Goldstand - Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B -BEGIN PGP SIGNATURE- Version: PGPfreeware 7.0.3 for non-commercial use http://www.pgp.com iQA/AwUBOq4VX4yEdnXg+lYbEQI8ngCgxZbrEAF1JpMuQ/SWV3jdMJp7EY8An38D kJn5xEGiYaV0ZBW27oBB3Vpk =rmm0 -END PGP SIGNATURE-
Re: to clarify (getting what was printed in PerlHandler)
I actually dont want to change whats outgoing -- I just want to know what it is.. - Original Message - From: "Ken Williams" [EMAIL PROTECTED] To: "JR Mayberry" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, March 12, 2001 7:20 PM Subject: Re: to clarify (getting what was printed in PerlHandler) [EMAIL PROTECTED] (JR Mayberry) wrote: Is it possible to retreive what was printed in the PerlHandler phase (what was called w/ $r-print()), in any of the post PerlHandler phases? [EMAIL PROTECTED] (JR Mayberry) wrote: a way to do it transparently...(ie: not changing code) i realize there are ways to do it otherwise.. Which code do you not want to change? Some code *somewhere* is going to have to change, or else (obviously) nothing different is going to happen. There are several ways to do this without changing any of the print statements, is that what you mean? ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: [OT] Client Certificate Authentification module?
If you download our Perl objects @ http://www.extropia.com/development/webware2/webware2.html, I have an AuthManager::Certificate which implements client certificate authentication. Probably the best place to download the code for that is on the extropiaperl project at sourceforge if you want to see the implementation. It's actually "trivial" because mod_ssl will decode the certificate into extra environment variables indicating stuff like the DN of the user. It's a requirement of SSL to make sure the certificate is valid based on the certificate's signature(s). At that point, then you need to deal with certificate revocation which is another matter. A lot of servers back up certificate authentication with LDAP. So the client sends the cert which verifies that they are who they say they are, but LDAP needs to be used to actually get the relevant authorization information out. If you use the framework we have, that is accomplished by configuring the use of AuthManager::Certificate against Auth::LDAP. Auth::Cache::Session can optionally be used to speed up the process. Chapter 20 on the link I gave you has details on why we broke up the modules the way we did. Note that this is not to be confused with a handler. This is application level logic. mod_ssl already handles certificate decoding so you really don't need a handler anymore. At that point it seems like app logic to take the user and figure out what you want them to do. Of course, you can code authorization info into a cert like the roles that they are intended for. But I think that's IMHO, a really BAD way to do it because you have to revoke the cert to change the permissions of the user. Best to leave the cert to identify the user and allow a dynamic datastore to determine what they can do in most cases. Later, Gunther PS The hard part about client certificates isn't using them, its managing them and the customers that use them. At 11:00 AM 3/13/01 +, [EMAIL PROTECTED] wrote: I am looking for a module that will allow me to use Client Certificates to authenticate the users. I am pretty sure I have come accros this before, but I cannot find it anywhere. Anybody know where I can find this. I have seached CPAN for 'cert', 'authen' and 'client', but unless I am overlooking something there doesn't seem to be anything there. Thank you very much. Kees Vonk Mailing Code 3 Joule 1 - Ground Floor Wharf Lane Solihull Internal: Phone: 7249 27705 E-Mail: Kees Vonk/KV002/Solihull/Transco Home Page: https://rep1prod:8081/ External: Phone: 0121 - 705 7581 ext. 27705 E-Mail: [EMAIL PROTECTED] __ The views expressed in this email are not necessarily the views of Transco plc, and the company, its directors, officers or employees make no representation or accept any liability for its accuracy or completeness unless expressly stated to the contrary. This e-mail, and any attachments are strictly confidential and intended for the addressee(s) only. The content may also contain legal, professional or other privileged information. If you are not the intended recipient, could you please notify the sender immediately and then delete the e-mail and any attachments, you should not disclose, copy or take any action in reliance of this transmission. Unless expressly stated to the contrary, no contracts may be concluded on behalf of Transco plc by means of e-mail communication. You may report the matter by calling us on +44 (0)1455 230999. You should not copy, forward or otherwise disclose the contents of this e-mail or any of its attachments without express consent. Please ensure you have adequate virus protection before you open or detach any documents from this transmission. Transco plc does not accept any liability for viruses. Transco plc is part of Lattice Group Transco plc is registered in England: Company number: 2006000 Registered Office: 130 Jermyn Street, London, SW1Y 4UR http://www.transco.uk.com __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/
Re: to clarify (getting what was printed in PerlHandler)
On Tue, 13 Mar 2001, JR Mayberry wrote: I actually dont want to change whats outgoing -- I just want to know what it is.. And the answer remains the same. Apache::Filter. -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: to clarify (getting what was printed in PerlHandler)
It's not really as plug and play as I was looking for.. I'm surprised that theres no built in functionality to allow any of the post-handler phases to be able to retreive what was dumped out... oh well.. - Original Message - From: "Matt Sergeant" [EMAIL PROTECTED] To: "JR Mayberry" [EMAIL PROTECTED] Cc: "Ken Williams" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, March 13, 2001 10:23 AM Subject: Re: to clarify (getting what was printed in PerlHandler) On Tue, 13 Mar 2001, JR Mayberry wrote: I actually dont want to change whats outgoing -- I just want to know what it is.. And the answer remains the same. Apache::Filter. -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** file://||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Error Pages
I have set up a cgi script that will display an error message and send an email to the administrator and placed that into the httpd.conf file via ErrorDocument 500 /cgi-bin/bad.pl I have about 30 different "Apps" that are native mod perl modules (written from scratch, not cgi converts). When one of these apps dies unexpectedly, it usually calls the bad.pl script and everything works the way it should. But about 10 percent of the time, apache sends the error to standard out, so the the browser sees something like: SQL Failure: SELECT * from all_tables: ORA-X: Some Obscure SQL Error No where in any of my code do I print a header until I'm finally ready to print every thing at once to the browser, so I shouldn't have sent any headers at the time the error occured. I also never print the errors. What could cause apache to send error messages to the browser rather than redirect to the bad.pl script? Thanks, Robert Landrum -- Warning: The contents of this message are made of bits which may or may not be an accurate representation of my thoughts.
Re: to clarify (getting what was printed in PerlHandler)
Well, the first time someone downloads a 100MB file from your site, you'll understand why apache doesn't save what it sends to the browser. The other solution is to assemble your outout into some sort of scalar, then check it within your handler and save whatever it is you're looking for into pnotes to be used in the post-handler. Just a thought... Robert Landrum It's not really as plug and play as I was looking for.. I'm surprised that theres no built in functionality to allow any of the post-handler phases to be able to retreive what was dumped out... oh well.. - Original Message - From: "Matt Sergeant" [EMAIL PROTECTED] To: "JR Mayberry" [EMAIL PROTECTED] Cc: "Ken Williams" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, March 13, 2001 10:23 AM Subject: Re: to clarify (getting what was printed in PerlHandler) On Tue, 13 Mar 2001, JR Mayberry wrote: I actually dont want to change whats outgoing -- I just want to know what it is.. And the answer remains the same. Apache::Filter. -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** file://||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\ -- Warning: The contents of this message are made of bits which may or may not be an accurate representation of my thoughts.
Re: $r and Registry(NG)* scripts
All scripts on site start with: use vars qw(%input $r); $r = Apache-request; This has worked fine...no complaints in log files...until I switched the handler from Registry to RegistryNG; Now I see occasional: Variable "$r" will not stay shared at /home/httpd/perl/daily-news.pl line 9 (#1) in log files. http://perl.apache.org/guide/troubleshooting.html#Value_of_x_will_not_stay_shared Thanks for the reply and the guide (of which I'm pretty familiar) Stas. See comments above and below. $r is global in my scripts. Unless I'm misunderstanding something, the warning shouldn't be occurring. Wasn't under Registry. Also these warnings do not appear on every page request, so I'm wondering if it has something to do with the compile stage of perlrun and/or something that happens during a new apache process creation. first nine from daily-news.pl: #!/usr/bin/perl -w use strict; use DBI; use date_site; my $dateformat = date_site::dateformat; use Apache::Request; use vars qw($dbh %input %output %filebase $r %sites); #vars used on $r $r = Apache-request; #--here Thanks, -- Daniel Bohling NewsFactor Network
Re: to clarify (getting what was printed in PerlHandler)
[EMAIL PROTECTED] (JR Mayberry) wrote: It's not really as plug and play as I was looking for.. I'm surprised that theres no built in functionality to allow any of the post-handler phases to be able to retreive what was dumped out... If you think about it, it would be a terrible idea to allow the kind of thing you're looking for. It would mean that when the programmer asks the output to be sent to the user, the web server instead doesn't send it, but piles it up somewhere just in case the programmer decides that he/she might want to look at it again. If the content is large, it would be a huge waste of memory resources, or of disk access (if cached), or the like. If you want to re-access the output you sent, you'll have to collect it yourself, or use the efforts that I and others have put into modules like Apache::Filter, which makes it easy. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: to clarify (getting what was printed in PerlHandler)
It's only saving it up until that request is done with.. I put it in a pnote..works fine.. - Original Message - From: "Ken Williams" [EMAIL PROTECTED] To: "JR Mayberry" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, March 13, 2001 2:56 PM Subject: Re: to clarify (getting what was printed in PerlHandler) [EMAIL PROTECTED] (JR Mayberry) wrote: It's not really as plug and play as I was looking for.. I'm surprised that theres no built in functionality to allow any of the post-handler phases to be able to retreive what was dumped out... If you think about it, it would be a terrible idea to allow the kind of thing you're looking for. It would mean that when the programmer asks the output to be sent to the user, the web server instead doesn't send it, but piles it up somewhere just in case the programmer decides that he/she might want to look at it again. If the content is large, it would be a huge waste of memory resources, or of disk access (if cached), or the like. If you want to re-access the output you sent, you'll have to collect it yourself, or use the efforts that I and others have put into modules like Apache::Filter, which makes it easy. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: [OT] Client Certificate Authentification module?
[EMAIL PROTECTED] wrote: I am looking for a module that will allow me to use Client Certificates to authenticate the users. I am pretty sure I have come accros this before, but I cannot find it anywhere. Anybody know where I can find this. I have seached CPAN for 'cert', 'authen' and 'client', but unless I am overlooking something there doesn't seem to be anything there. You might want to look at mod_ssl and OpenSSL. They can mimic basic authentication with client certificates. -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
Handler without handler()
I have a handler that I want to contain all of my methods for access control, authentication and authorization. I have created the file with 3 different methods named access($$), authentication($$) and authorization($$). I have these methods set up thusly in the httpd.conf file: Directory /usr/local/cgi-bin PerlHandler Apache::Registry AuthType Me::MyHandler AuthName Me PerlAccessHandler Me::MyHandler-access PerlAuthenHandler Me::MyHandler-authenticate PerlAuthzHandler Me::MyHandler-authorize PerlInitHandler Apache::StatINC PerlSetVar StatINCDebug On require valid-user /Directory Unfortunately, every time I try and access a cgi in that directory, I get the following errors: Can't locate object method "access" via package "Me::MyHandler" access.pm: Can't locate access.pm in @INC So I have a couple of questions: 1) Can I write a handler that doesn't have a method named 'handler'? 2) If so, what do I have to put in the httpd.conf file to allow Apache to properly access the handler methods? Thanks, Gene Dascher
Re: Handler without handler()
Gene Dascher wrote: I have a handler that I want to contain all of my methods for access control, authentication and authorization. I have created the file with 3 different methods named access($$), authentication($$) and authorization($$). I have these methods set up thusly in the httpd.conf file: Directory /usr/local/cgi-bin PerlHandler Apache::Registry AuthType Me::MyHandler AuthName Me PerlAccessHandler Me::MyHandler-access PerlAuthenHandler Me::MyHandler-authenticate PerlAuthzHandler Me::MyHandler-authorize PerlInitHandler Apache::StatINC PerlSetVar StatINCDebug On require valid-user /Directory Unfortunately, every time I try and access a cgi in that directory, I get the following errors: Can't locate object method "access" via package "Me::MyHandler" access.pm: Can't locate access.pm in @INC So I have a couple of questions: 1) Can I write a handler that doesn't have a method named 'handler'? Yes, you can write a handler that doesn't have a sub named 'handler'. 2) If so, what do I have to put in the httpd.conf file to allow Apache to properly access the handler methods? I believe you need to specify the subroutine. Otherwise the handler sub is assumed. Thanks, Gene Dascher ~Sean
Re: Handler without handler()
I believe that you need to load your module first, either in a startup file or with PerlModule Me::MyHandler Gene Dascher wrote: I have a handler that I want to contain all of my methods for access control, authentication and authorization. I have created the file with 3 different methods named access($$), authentication($$) and authorization($$). I have these methods set up thusly in the httpd.conf file: Directory /usr/local/cgi-bin PerlHandler Apache::Registry AuthType Me::MyHandler AuthName Me PerlAccessHandler Me::MyHandler-access PerlAuthenHandler Me::MyHandler-authenticate PerlAuthzHandler Me::MyHandler-authorize PerlInitHandler Apache::StatINC PerlSetVar StatINCDebug On require valid-user /Directory Unfortunately, every time I try and access a cgi in that directory, I get the following errors: Can't locate object method "access" via package "Me::MyHandler" access.pm: Can't locate access.pm in @INC So I have a couple of questions: 1) Can I write a handler that doesn't have a method named 'handler'? 2) If so, what do I have to put in the httpd.conf file to allow Apache to properly access the handler methods? Thanks, Gene Dascher
Re: $r and Registry(NG)* scripts
On Tue, 13 Mar 2001, Daniel wrote: All scripts on site start with: use vars qw(%input $r); $r = Apache-request; This has worked fine...no complaints in log files...until I switched the handler from Registry to RegistryNG; Now I see occasional: Variable "$r" will not stay shared at /home/httpd/perl/daily-news.pl line 9 (#1) in log files. http://perl.apache.org/guide/troubleshooting.html#Value_of_x_will_not_stay_shared Thanks for the reply and the guide (of which I'm pretty familiar) Stas. See comments above and below. $r is global in my scripts. Unless I'm misunderstanding something, the warning shouldn't be occurring. Wasn't under Registry. Also these warnings do not appear on every page request, so I'm wondering if it has something to do with the compile stage of perlrun and/or something that happens during a new apache process creation. Sorry, I've jumped too fast with a conclusion at seeing the standard "...will not stay shared". But in order to debug the problem, I have to be able to reproduce it. Are you saying that the script below, as it is, has this problem? But it's not the whole script, I understand. Can you write a small reproducing test? first nine from daily-news.pl: #!/usr/bin/perl -w use strict; use DBI; use date_site; my $dateformat = date_site::dateformat; use Apache::Request; use vars qw($dbh %input %output %filebase $r %sites); #vars used on $r $r = Apache-request; #--here Thanks, -- Daniel Bohling NewsFactor Network _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: cgi_to_mod_perl manpage suggestion
On Tue, 13 Mar 2001, Issac Goldstand wrote: The only problem was the PerlSendHeaders option. The first fifty or so times that I read the manpages, I understood that PerlSendHeader On means that mod_perl will SEND HEADERS, and that off meant supply your own... Somehow I figured out (eventually) that this was not so, switched all of my deliberately placed PerlSendHeader Off statesments to a single On statement, and all of my scripts once again work. Um, you're getting me confused now, but PerlSendHeader On means that mod_perl WILL send headers. I think the main problem was the line : By default, mod_perl does not send any headers by itself, however, you may wish to change this: PerlSendHeader On That seems to say that if you want mod_perl to handle headers for you, cange it to On. That's correct. - Perrin
Re: cgi_to_mod_perl manpage suggestion
Hello, PHUm, you're getting me confused now, but PerlSendHeader On means that PHmod_perl WILL send headers. I recognize this confusion. Most recovering CGI programmers think that "PerlSendHeader On" means that you no longer have to do this in your CGI: print "Content-type: text/html\n\n"; When in fact you still do. The manpage makes it sound like you don't. Perhaps a note to that effect would be helpful. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: cgi_to_mod_perl manpage suggestion
On Tue, 13 Mar 2001, Andrew Ho wrote: PHUm, you're getting me confused now, but PerlSendHeader On means that PHmod_perl WILL send headers. I recognize this confusion. Most recovering CGI programmers think that "PerlSendHeader On" means that you no longer have to do this in your CGI: print "Content-type: text/html\n\n"; When in fact you still do. The manpage makes it sound like you don't. Perhaps a note to that effect would be helpful. I certainly want newbies to understand the docs, but the man page does say very explicitly "Just as with mod_cgi, PerlSendHeader will not send the MIME type and a terminating double newline. Your script must send that itself..." - Perrin
Re: [gsar@ActiveState.com: v5.6.1 trial2 is available]
On Tue, 13 Mar 2001 17:10:41 CST, Jarkko Hietaniemi wrote: sorry for not answering sooner. The suggested patch seems to work find with the development branch of Perl, and I believe Sarathy will apply the patch also to the maintenance branch. There is a change in behavior here that looks somewhat suspect because the comments didn't mention it. On Wed, Feb 21, 2001 at 09:32:04PM +0100, Jens-Uwe Mager wrote: +#ifdef USE_NATIVE_DLOPEN [...] +#else [...] +#ifndef RTLD_LAZY +# define RTLD_LAZY 0 +#endif +#ifndef RTLD_GLOBAL +# define RTLD_GLOBAL 0 +#endif [...] -RETVAL = dlopen(filename, 1) ; +RETVAL = dlopen(filename, RTLD_GLOBAL|RTLD_LAZY) ; It seems to me that dlopen() is now being called with a second argument of 0 instead of 1 if USE_NATIVE_DLOPEN wasn't set and those two constants aren't defined in the system headers. Is this an intentional change? Does it have potential to break anything on the pre-4.3 AIX versions? Sarathy [EMAIL PROTECTED]
cvs commit: modperl-2.0/src/modules/perl mod_perl.c modperl_util.c modperl_util.h
dougm 01/03/13 20:22:51
Modified:src/modules/perl mod_perl.c modperl_util.c modperl_util.h
Log:
add modperl_server_desc() function
add more trace details when initializing the interpreter pool
Revision ChangesPath
1.30 +25 -6 modperl-2.0/src/modules/perl/mod_perl.c
Index: mod_perl.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- mod_perl.c2001/03/09 23:46:34 1.29
+++ mod_perl.c2001/03/14 04:22:51 1.30
@@ -93,7 +93,7 @@
*/
if (MpSrvPARENT(scfg) || MpSrvCLONE(scfg)) {
MP_TRACE_i(MP_FUNC, "modperl_interp_init() server=%s\n",
- s-server_hostname);
+ modperl_server_desc(s, p));
modperl_interp_init(s, p, perl);
}
@@ -118,20 +118,39 @@
#ifdef USE_ITHREADS
static void modperl_init_clones(server_rec *s, apr_pool_t *p)
{
+#ifdef MP_TRACE
+modperl_srv_config_t *base_scfg = modperl_srv_config_get(s);
+char *base_name = modperl_server_desc(s, p);
+#endif /* MP_TRACE */
+
for (; s; s=s-next) {
MP_dSCFG(s);
+#ifdef MP_TRACE
+char *name = modperl_server_desc(s, p);
+#endif /* MP_TRACE */
+
if (scfg-mip-tipool-idle) {
-MP_TRACE_i(MP_FUNC, "%s interp already cloned\n",
- s-server_hostname);
+#ifdef MP_TRACE
+if (scfg-mip == base_scfg-mip) {
+MP_TRACE_i(MP_FUNC,
+ "%s interp pool inherited from %s\n",
+ name, base_name);
+}
+else {
+MP_TRACE_i(MP_FUNC,
+ "%s interp pool already initialized\n",
+ name);
+}
+#endif /* MP_TRACE */
}
else {
-MP_TRACE_i(MP_FUNC, "cloning interp for %s\n",
- s-server_hostname);
+MP_TRACE_i(MP_FUNC, "initializing interp pool for %s\n",
+ name);
modperl_tipool_init(scfg-mip-tipool);
}
}
}
-#endif
+#endif /* USE_ITHREADS */
void modperl_hook_init(apr_pool_t *pconf, apr_pool_t *plog,
apr_pool_t *ptemp, server_rec *s)
1.5 +5 -0 modperl-2.0/src/modules/perl/modperl_util.c
Index: modperl_util.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.c,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- modperl_util.c2001/03/13 05:09:02 1.4
+++ modperl_util.c2001/03/14 04:22:51 1.5
@@ -81,3 +81,8 @@
return status;
}
+
+char *modperl_server_desc(server_rec *s, apr_pool_t *p)
+{
+return apr_psprintf(p, "%s:%u", s-server_hostname, s-port);
+}
1.5 +2 -0 modperl-2.0/src/modules/perl/modperl_util.h
Index: modperl_util.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.h,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- modperl_util.h2001/03/09 23:46:36 1.4
+++ modperl_util.h2001/03/14 04:22:51 1.5
@@ -20,4 +20,6 @@
int modperl_require_module(pTHX_ const char *pv);
+char *modperl_server_desc(server_rec *s, apr_pool_t *p);
+
#endif /* MODPERL_UTIL_H */
cvs commit: modperl-2.0/src/modules/perl modperl_interp.c
dougm 01/03/13 22:57:44
Modified:src/modules/perl modperl_interp.c
Log:
share selected Perl interpreter across sub-requests by default
Revision ChangesPath
1.21 +10 -5 modperl-2.0/src/modules/perl/modperl_interp.c
Index: modperl_interp.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_interp.c,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- modperl_interp.c 2001/03/14 05:22:49 1.20
+++ modperl_interp.c 2001/03/14 06:57:43 1.21
@@ -202,12 +202,14 @@
*/
#define MP_INTERP_KEY "MODPERL_INTERP"
-modperl_interp_t *modperl_interp_select(request_rec *r, conn_rec *c,
+modperl_interp_t *modperl_interp_select(request_rec *rr, conn_rec *c,
server_rec *s)
{
MP_dSCFG(s);
modperl_interp_t *interp;
apr_pool_t *p = NULL;
+int is_subrequest = (rr rr-main) ? 1 : 0;
+request_rec *r = is_subrequest ? rr-main : rr;
const char *desc = NULL;
int lifetime_connection =
(modperl_interp_lifetime_connection(scfg) || !r);
@@ -231,8 +233,9 @@
if (interp) {
MP_TRACE_i(MP_FUNC,
- "found interp 0x%lx in %s 0x%lx\n",
- (unsigned long)interp, desc, (unsigned long)r-pool);
+ "found interp 0x%lx in %s 0x%lx (%s request for %s)\n",
+ (unsigned long)interp, desc, (unsigned long)r-pool,
+ (is_subrequest ? "sub" : "main"), rr-uri);
return interp;
}
@@ -267,8 +270,10 @@
/* set context (THX) for this thread */
PERL_SET_CONTEXT(interp-perl);
-MP_TRACE_i(MP_FUNC, "set interp 0x%lx in %s 0x%lx\n",
- (unsigned long)interp, desc, (unsigned long)p);
+MP_TRACE_i(MP_FUNC, "set interp 0x%lx in %s 0x%lx (%s request for %s)\n",
+ (unsigned long)interp, desc, (unsigned long)p,
+ (r ? (is_subrequest ? "sub" : "main") : "conn"),
+ (r ? rr-uri : c-remote_ip));
return interp;
}
