cvs commit: modperl-2.0/xs/Apache/Filter Apache__Filter.h
stas2002/07/01 00:08:45 Modified:xs/Apache/Filter Apache__Filter.h Log: fix a typo: s/output/input/ Revision ChangesPath 1.19 +1 -1 modperl-2.0/xs/Apache/Filter/Apache__Filter.h Index: Apache__Filter.h === RCS file: /home/cvs/modperl-2.0/xs/Apache/Filter/Apache__Filter.h,v retrieving revision 1.18 retrieving revision 1.19 diff -u -r1.18 -r1.19 --- Apache__Filter.h 25 Jan 2002 04:04:22 - 1.18 +++ Apache__Filter.h 1 Jul 2002 07:08:45 - 1.19 -2,7 +2,7 ap_add_output_filter(name, ctx, r, NULL) #define mpxs_Apache__RequestRec_add_input_filter(r, name, ctx) \ -ap_add_output_filter(name, ctx, r, NULL) +ap_add_input_filter(name, ctx, r, NULL) #define mp_xs_sv2_modperl_filter(sv) \ ((SvROK(sv) (SvTYPE(SvRV(sv)) == SVt_PVMG)) \
Re: Optional HTTP Authentication ?
However, if the structure were http://bigmegamarket.com/index.pl/56765454151/grocery/fruits/bananas, say, with the number being the session ID, the URL then is hackable within that (good) definition. Yes, however there are quite a number of issues with bookmarks and search engines... But that's for sure another interesting and less-ugly option. I'm a big fan of cookies myself, for the thing they were made for, namely session tracking. I share your frustration :-(. Yep. It's a shame that cookies which were a good idea at first get such a bad name because of all these moronic marketing companies which dream of knowing you inside out to send you more shit spam abuse them. But I'm off topic here :-) Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
browser sent the credentials, or leave $ENV{REMOTE_USER} undef
otherwise, without sending a 401 back.
I didn't think a browser would send authentication unless the server
requested it for an authentication domain. How are you going to
get some people to send the credentials and some not unless you
use different URLs so the server knows when to request them?
The idea is that on a location which requires authentication I'll
redirect the user to a /login.html, or maybe a /?login=1 which will do
the following:
IF user is authenticated = redirect to location it came from
ELSE send 401 authorization required
This way users should get a login box strictly when necessary. Almost
all the request go thru an Apache::Registry friendly CGI script:
Alias /.static /opt/chico/static
Alias //opt/mkd/cgi/mkdoc.cgi/
Everything is treated using $ENV{PATH_INFO} in the script, and the
script knows when something needs authentication or not.
Note that you don't have to embed session info here, just add
some element to the URL that serves as the point where you
request credentials and omit it for people that don't log in. Or
redirect to a different vhost that always requires authentication but
serves the same data.
Oh but I have that already. I know that I need to password protect
/properties.html
/content.html
/move.html
/foo/properties.html
/foo/content.html
/foo/move.html
etc...
Is it possible to password-protect a class of URIs using regexes? That
would be another good option.
Cheers,
--
IT'S TIME FOR A DIFFERENT KIND OF WEB
Jean-Michel Hiver - Software Director
[EMAIL PROTECTED]
+44 (0)114 255 8097
VISIT HTTP://WWW.MKDOC.COM
Re: Commercial use of mod_perl / modules]
On 29 Jun 2002 01:46:00 +0400, Ilya Martynov wrote: On Fri, 28 Jun 2002 16:38:25 -0500, Stephen Clouse [EMAIL PROTECTED] said: SC On Fri, Jun 28, 2002 at 01:09:21PM +0100, Peter Haworth wrote: The GPL doesn't restrict use, only distribution. SC I believe you need to read it again. Its whole purpose of SC existence is to restrict use by non-free software. Link GPL code SC into your non-free app at your own risk. AFAIK it is OK as long as you do not distribute the result. Admittedly, it has been some time since I read it. However, I've just done so. Here are some quotes: 0. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program Running the program, and it's output are not restricted. Otherwise, everything compiled by gcc would be under GPL, which it isn't. 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. This is the only condition in section 2 which mentions distribution. It doesn't say you have to distribute; only what applies if you do. These are from the GPL FAQ: A system incorporating a GPL-covered program is an extended version of that program. The GPL says that any extended version of the program must be released under the GPL if it is released at all. But from my reading (which could be wrong, of course), it doesn't say that you have to release it. What the GPL requires is that [someone with a copy of a GPL'ed program] must have the freedom to distribute a copy to you if he wishes to. -- Peter Haworth [EMAIL PROTECTED] Who is General Failure and why is he reading my disk?
RE: mod_perl 1.99 on Win2k with Apache2
Greetings. Nigel Peck wrote: Thanks for the help. When did I reply to you privately? This was just to reiterate for everybody to keep the threads on the list. Since many times those who respond to the questions, suffer afterwards because people decide that the person answering the question, is a free help desk that you can ask about anything, not talking about [...] Stas, as one that has been guilty of the same offence, let me point out that 99.9% of the time, seemingly private responses emerge from the list manager's policy of not munging the Reply-to: header - so the poor schmuck (me) hits reply and fires off a private reply to the poster. I know all about Reply-to: munging considered harmful and attending flame wars and I do not wish to delve into the relative pros and cons of the diveded camps (I'll just say that the lists I administer do the munging - period). What I wish to do is pointing out that - on non-munging lists - most standard clients require a conscious decision if they want to reply to the list, despite the fact that this would be the actual intention most of the times (so it makes for a poor interface). People stuck - like me - in Outlook-land have it even worse than most. Just my 0.02 cheers, alf
Re: mod_perl 1.99 on Win2k with Apache2
Alessandro Forghieri wrote: Greetings. Nigel Peck wrote: Thanks for the help. When did I reply to you privately? This was just to reiterate for everybody to keep the threads on the list. Since many times those who respond to the questions, suffer afterwards because people decide that the person answering the question, is a free help desk that you can ask about anything, not talking about [...] Stas, as one that has been guilty of the same offence, let me point out that 99.9% of the time, seemingly private responses emerge from the list manager's policy of not munging the Reply-to: header - so the poor schmuck (me) hits reply and fires off a private reply to the poster. I know all about Reply-to: munging considered harmful and attending flame wars and I do not wish to delve into the relative pros and cons of the diveded camps (I'll just say that the lists I administer do the munging - period). What I wish to do is pointing out that - on non-munging lists - most standard clients require a conscious decision if they want to reply to the list, despite the fact that this would be the actual intention most of the times (so it makes for a poor interface). People stuck - like me - in Outlook-land have it even worse than most. I'm +1 on using a preset 'Reply-to:' header. httpd-dev seems to use it solely for the reason you describe. I'm all for helping people to reply back to the list. Ask, can we please have this header set? -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Fwd: Re: param trouble
Thanks to everyone giving their hints and help. I will try to search the archive again Jean-Michel as it looks v. similar. At the moment I'm lucky that I got my data in the url so in the end I just applied a regex. Cheers, Tim -- Forwarded Message -- Subject: Re: param trouble Date: Sun, 30 Jun 2002 11:32:46 +0100 From: Jean-Michel Hiver [EMAIL PROTECTED] To: Tim Sebastian Böckers [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] basically the whole thing is starting to bite its own tail and i would be very happy if anybody could give me any pointers as to why CGI won't read my data from the PerlInitHandler or after Apache::Request read them. I seem to remember a post where someone had trouble because he was trying to access POSTed data twice... problem was that once the POSTed data was read, that was it. Maybe it's something similar? Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM ---
Re: Optional HTTP Authentication ?
From: Jean-Michel Hiver [EMAIL PROTECTED] Oh but I have that already. I know that I need to password protect /properties.html /content.html /move.html /foo/properties.html /foo/content.html /foo/move.html etc... Is it possible to password-protect a class of URIs using regexes? That would be another good option. I thought you meant that you wanted the same location to be accessed by different people with/without passwords. You should be able to put the authentication directives in a LocationMatch container in this case. Another approach would be to use mod_rewrite to map the request to a directory containing a symlink to the script and an appropriate .htaccess file. This is kind of brute-force but it lets you do anything you want with a request including proxying to an otherwise unreachable port or server for certain content. Unfortunately I think the symlink approach appears as a different script to mod_perl so it will cache a separate copy in memory. Les Mikesell [EMAIL PROTECTED]
Re: Optional HTTP Authentication ?
On Mon, Jul 01, 2002 at 10:30:36AM +0100, Jean-Michel Hiver wrote:
browser sent the credentials, or leave $ENV{REMOTE_USER} undef
otherwise, without sending a 401 back.
I didn't think a browser would send authentication unless the server
requested it for an authentication domain. How are you going to
get some people to send the credentials and some not unless you
use different URLs so the server knows when to request them?
The idea is that on a location which requires authentication I'll
redirect the user to a /login.html, or maybe a /?login=1 which will do
the following:
Umm... Perhaps I don't understand the significance of the login.html. Under
HTTP auth, if a page is protected via .htaccess then auth is immediatly
requested, and no redirect is possible.
More important is the fact that if a page does not require authentication,
the users login and password will not be sent. So a page like index.html that
is not normally authenticated will not receive the username, and no
a href=/adminAdmin this page/a will be possible.
I'm not 100% sure this is possible without the use of cookies. I'm pretty sure
you could write some custom handler to handle the auth, but without a cookie
to note which users have authenticated, you might be out of luck.
Good luck,
Rob
Re: Optional HTTP Authentication ?
Thanks to the list and two days of hard work, I have my optional HTTP
authentication thingie working :-)
Basically here is how it looks in my apache config file:
# This method handler ensures that users must enter their credentials
# for any URI which looks like /foo/bar/login.html
LocationMatch .*/login.html$
AuthName MKDoc Login
AuthType Basic
PerlAuthenHandler MKDoc::Auth::SQL_HTTP-handler
require valid-user
/LocationMatch
# This method handler affects the whole site, it sets the
# $ENV{REMOTE_USER} variable if the credentials have been sent, or
# leave it undef otherwise.
Location /
PerlFixupHandler
MKDoc::Auth::SQL_HTTP-handler_opt
/Location
# if the user successfully logged in when hitting a /foo/bar/login.html
# location, then we want to redirect him where he came from
LocationMatch .*/login.html$
SetHandler perl-script
PerlHandler
MKDoc::Auth::SQL_HTTP-handler_redirect
require valid-user
/LocationMatch
more perl handlers here
* Now if you go to /properties.html BEFORE sending the credentials,
* You're redirected to /login.html?from=/properties.html where you login,
* Which redirects you to /properties.html... but this time your browser
sends the credentials!
This is interesting because it's up to the handlers to decide wether
they need authentication or not and does non depend on the location.
More important is the fact that if a page does not require authentication,
the users login and password will not be sent. So a page like index.html that
is not normally authenticated will not receive the username, and no
a href=/adminAdmin this page/a will be possible.
This is not true, once you've entered the credentials on /login.html the
browsers send them everywhere. Tested under Opera (Linux), Mozilla
(Linux) and IE from version 3 to version 6 (Windows), IE 3 (Mac),
Netscape 4 (Mac).
One exception: links :-(. But the browser support seems to be there...
In the future I plan to have some kind of hybrid handler which would
accept either HTTP credentials OR a cookie... that would be cool :-)
I'm not 100% sure this is possible without the use of cookies. I'm pretty sure
you could write some custom handler to handle the auth, but without a cookie
to note which users have authenticated, you might be out of luck.
Well I seem to have done it, so it must be possible thanks to you guys
;-. I will send the code to anyone who's interested but I don't want
to post it to the list because I suspect that most people aren't.
Thank you everyone,
Cheers,
--
IT'S TIME FOR A DIFFERENT KIND OF WEB
Jean-Michel Hiver - Software Director
[EMAIL PROTECTED]
+44 (0)114 255 8097
VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
Hi there, On 30 Jun 2002, Randal L. Schwartz wrote: What? The EU is going to make cookies *illegal*? I highly doubt this. There is already EU legislation which might make the use of cookies suspect. It concerns, for example, the monitoring of individual keyboard operators to measure their performance. That's been illegal in the EU for some time. You only have to start counting your cookies to be treading on shaky ground. 73, Ged. BTW it's modperlatperldotapachedotorg
Re: Optional HTTP Authentication ?
Jean-Michel Hiver [EMAIL PROTECTED] writes: However, if the structure were http://bigmegamarket.com/index.pl/56765454151/grocery/fruits/bananas, say, with the number being the session ID, the URL then is hackable within that (good) definition. Yes, however there are quite a number of issues with bookmarks and search engines... But that's for sure another interesting and less-ugly option. Very true. I was solving only the stated problem, and didn't think much about the other problems that would then appear. I'm a big fan of cookies myself, for the thing they were made for, namely session tracking. I share your frustration :-(. Yep. It's a shame that cookies which were a good idea at first get such a bad name because of all these moronic marketing companies which dream of knowing you inside out to send you more shit spam abuse them. But I'm off topic here :-) And that's all it is; a bad *name*. With the option to refuse to deliver cookies to a domain different from the domain of the top-level page, they have no actual problems. And they solve the problem they're supposed to solve nearly perfectly. Obviously for individual projects one has to do what the people with the checkbook say, but we shouldn't be just rolling over on cookies; we should be arguing the point strenuously. -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
Re: mod_perl 1.99 on Win2k with Apache2
Stas Bekman [EMAIL PROTECTED] writes: I'm +1 on using a preset 'Reply-to:' header. httpd-dev seems to use it solely for the reason you describe. I'm all for helping people to reply back to the list. Ask, can we please have this header set? Can we please *not*? -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
Apache::LogFile issues
Hello everyone, I'm attempting to implement Apache::LogFile on our production servers and running into some problems. It seems to work fine on our development server, which is running Apache 1.3.20, except for the fact that we can no longer issue 'apachectl restart', we have to stop and start the webserver for it to work. When we attempt a restart, the following error occurs: -- Syntax error on line 1097 of /usr/local/apachessl/conf/httpd.conf: Invalid command 'PerlLogFile', perhaps mis-spelled or defined by a module not included in the server configuration -- ( PerlFreshRestart is On ) On our production server, we are running Apache 1.3.24, and I cannot get the webserver to start with the Apache::LogFile code in the conf file. It always dies with the above error, whether I stop and start or just restart. The relavant lines from the httpd.conf file are: -- PerlModule Apache::LogFile PerlLogFile '|bin/rotatelogs /var/spool/ad_automator/logs/activity_log 3600' AdAutomator::Logger -- Thanks to anyone who can help! - Jim
Re: Apache::LogFile issues
On our production server, we are running Apache 1.3.24, and I cannot get the webserver to start with the Apache::LogFile code in the conf file. It always dies with the above error, whether I stop and start or just restart. The relavant lines from the httpd.conf file are: -- PerlModule Apache::LogFile PerlLogFile '|bin/rotatelogs /var/spool/ad_automator/logs/activity_log 3600' AdAutomator::Logger you need PerlModule Apache::LogFile::Config in your httpd.conf as well (with recent versions of mod_perl). HTH --Geoff
apache 1.3.26 reverse proxy
Has anyone noticed any performance problems using 1.3.26 as the front end proxy to a backend mod_perl server? I upgraded a box running apache 1.3.22 as the frontend proxy to 1.3.26. Prior to upgrading the load was ~2.0 - 3.0. After upgrading, the load went up to around 21 - 25. I then downgraded and the load went back to normal. Could this have anything to do with the changes to mod_proxy between 1.3.22 and 1.3.26? Any ideas? --eric
Re: apache 1.3.26 reverse proxy
E Kolve [EMAIL PROTECTED] writes: Has anyone noticed any performance problems using 1.3.26 as the front end proxy to a backend mod_perl server? I upgraded a box running apache 1.3.22 as the frontend proxy to 1.3.26. Prior to upgrading the load was ~2.0 - 3.0. After upgrading, the load went up to around 21 - 25. I then downgraded and the load went back to normal. Could this have anything to do with the changes to mod_proxy between 1.3.22 and 1.3.26? Any ideas? You don't actually talk about any performance problem. Were the proxied requests in fact running slowly? It seems to me a difference in the process structure or what how they wait could have horrible effects on the load average numbers while actually improving performance. Or not. -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
Re: apache 1.3.26 reverse proxy
I was watching the apache scoreboard file and it appeared the the mod_perl process was not being immediately freed by the proxy. Normally there will be 3 or 4 mod_perl procs in mode W Sending Reply, but after around 20 - 30 seconds on 1.3.26 as the proxy all 30 (that is my MaxClients for mod_perl) were in W. This seems like a problem with either the IOBufferSize that was recently added or possibly something to do with the proxy not releasing the mod_perl process once it has gotten the last byte... --eric David Dyer-Bennet wrote: E Kolve [EMAIL PROTECTED] writes: Has anyone noticed any performance problems using 1.3.26 as the front end proxy to a backend mod_perl server? I upgraded a box running apache 1.3.22 as the frontend proxy to 1.3.26. Prior to upgrading the load was ~2.0 - 3.0. After upgrading, the load went up to around 21 - 25. I then downgraded and the load went back to normal. Could this have anything to do with the changes to mod_proxy between 1.3.22 and 1.3.26? Any ideas? You don't actually talk about any performance problem. Were the proxied requests in fact running slowly? It seems to me a difference in the process structure or what how they wait could have horrible effects on the load average numbers while actually improving performance. Or not.
IndigoPerl Apache not responding
I downloaded IndigoPerl. I started theApache server and it says at the top of it [warn] pid file c:/unzipped/indigoperl5-6/logs/gttpd.pid overwritten -- unclean shutdown of previous Apache run? Apache/1.3.20 (Win32) mod_perl1.25 running... but when I try to type something it doesn't respond. Should I uninstall the program and reinstall it and unzip it differently? What does the unclean shut down mean? Thanks a bunch, wickham26Do You Yahoo!? Sign-up for Video Highlights of 2002 FIFA World Cup
RE: IndigoPerl Apache not responding
Melissa, You can ignore the unclean shutdown message - it just means Apache wasn't stopped gracefully via the command to stop it. On windows, I always do ctrl-c to stop it. For production, you will probably install it as a service and use the services controller(in Administrative Tools of Control Panel) to start stop it. As far as typing somthing in, you don't. Apache has no user interface, it just sits there listening for someone to talk http protocol to it. You control how Apache operates by putting Directives in its configuration files (in the conf directory under the Apache directory). Apache is running when it doesn't kick you back to the command prompt. When Apache is running you can enter http:// folowed by the ip address of the machine and you should get a web page back. Haven't heard of IndigoPerl, but it sounds like they have built (with a compiler from the source files) Apache and perl and put them in a zip to make things easier. Read their stuff (http://www.indigostar.com/indigoperl.htm) and look at their site to find out about configuring the server. Also see apache.org and perl.com for more information. Chuck -Original Message- From: Melissa [mailto:[EMAIL PROTECTED]] Sent: Monday, July 01, 2002 4:02 PM To: [EMAIL PROTECTED] Subject: IndigoPerl Apache not responding I downloaded IndigoPerl. I started the Apache server and it says at the top of it [warn] pid file c:/unzipped/indigoperl5-6/logs/gttpd.pid overwritten -- unclean shutdown of previous Apache run? Apache/1.3.20 (Win32) mod_perl1.25 running... but when I try to type something it doesn't respond. Should I uninstall the program and reinstall it and unzip it differently? What does the unclean shut down mean? Thanks a bunch, wickham26 Do You Yahoo!? Sign-up for Video Highlights of 2002 FIFA World Cup
cvs commit: modperl/htdocs/manual/mod mod_perl.html
stas2002/07/01 08:17:09 Modified:htdocs/manual/mod mod_perl.html Log: tidy up the mod_perl manual to comply with xhtml standard: % tidy -mi -asxml -wrap 80 mod_perl.html Submitted by: Rich Bowen [EMAIL PROTECTED] Revision ChangesPath 1.2 +751 -661 modperl/htdocs/manual/mod/mod_perl.html Index: mod_perl.html === RCS file: /home/cvs/modperl/htdocs/manual/mod/mod_perl.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- mod_perl.html 19 Mar 1998 23:08:41 - 1.1 +++ mod_perl.html 1 Jul 2002 15:17:09 - 1.2 @@ -1,662 +1,752 @@ -HTML -HEADTITLEApache module mod_perl/TITLE/HEAD +!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN +http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; + +html xmlns=http://www.w3.org/1999/xhtml; + head +meta name=generator content=HTML Tidy, see www.w3.org / + +titleApache module mod_perl/title + /head + + body bgcolor=#FF text=#00 link=#FF vlink=#80 + alink=#FF +!-- generated by Apache::ModuleDoc 1.1 -- + +div align=CENTER + img src=../images/sub.gif alt=[APACHE DOCUMENTATION] / + + h3Apache HTTP Server Version 1.3/h3 +/div + +h1 align=CENTERModule mod_perl/h1 + +pThis module is contained in the mod_perl.c file./p + +ul + lia href=#.Perl.lt;Perlgt;/a/li + lia href=#./Perl.lt;/Perlgt;/a/li + lia href=#=pod=pod/a/li + lia href=#=cut=cut/a/li + lia href=#__ENDEND__/a/li + lia href=#PerlAccessHandlerPerlAccessHandler/a/li + lia href=#PerlAuthenHandlerPerlAuthenHandler/a/li + lia href=#PerlAuthzHandlerPerlAuthzHandler/a/li + lia href=#PerlChildExitHandlerPerlChildExitHandler/a/li + lia href=#PerlChildInitHandlerPerlChildInitHandler/a/li + lia href=#PerlCleanupHandlerPerlCleanupHandler/a/li + lia href=#PerlDispatchHandlerPerlDispatchHandler/a/li + lia href=#PerlFixupHandlerPerlFixupHandler/a/li + lia href=#PerlFreshRestartPerlFreshRestart/a/li + lia href=#PerlHandlerPerlHandler/a/li + lia href=#PerlHeaderParserHandlerPerlHeaderParserHandler/a/li + lia href=#PerlInitHandlerPerlInitHandler/a/li + lia href=#PerlLogHandlerPerlLogHandler/a/li + lia href=#PerlModulePerlModule/a/li + lia href=#PerlPassEnvPerlPassEnv/a/li + lia href=#PerlPostReadRequestHandlerPerlPostReadRequestHandler/a/li + lia href=#PerlRequirePerlRequire/a/li + lia href=#PerlRestartHandlerPerlRestartHandler/a/li + lia href=#PerlScriptPerlScript/a/li + lia href=#PerlSendHeaderPerlSendHeader/a/li + lia href=#PerlSetEnvPerlSetEnv/a/li + lia href=#PerlSetVarPerlSetVar/a/li + lia href=#PerlSetupEnvPerlSetupEnv/a/li + lia href=#PerlTaintCheckPerlTaintCheck/a/li + lia href=#PerlTransHandlerPerlTransHandler/a/li + lia href=#PerlTypeHandlerPerlTypeHandler/a/li + lia href=#PerlWarnPerlWarn/a/li +/ul +hr / + +h2a id=.Perl. name=.Perl.lt;Perlgt; directive/a/h2 + +pDescription: Perl codebr / +br / + a href=directive-dict.html#Syntax +rel=HelpstrongSyntax:/strong/a lt;Perlgt; emRaw Text/em +(RAW_ARGS)br / + a href=directive-dict.html#PerlSyntax +rel=HelpstrongPerlSyntax:/strong/a ttN/A/ttbr / + a href=directive-dict.html#Context +rel=HelpstrongContext:/strong/a Allowed in *.conf anywhere and in +.htaccessbr / + a href=directive-dict.html#Override +rel=HelpstrongOverride:/strong/a Any other than Nonebr / + a href=directive-dict.html#Status +rel=HelpstrongStatus:/strong/a Extensionbr / + a href=directive-dict.html#Module +rel=HelpstrongModule:/strong/a mod_perl/p +hr / + +h2a id=./Perl. name=./Perl.lt;/Perlgt; directive/a/h2 + +pDescription: End Perl codebr / +br / + a href=directive-dict.html#Syntax +rel=HelpstrongSyntax:/strong/a lt;/Perlgt; (NO_ARGS)br / + a href=directive-dict.html#PerlSyntax +rel=HelpstrongPerlSyntax:/strong/a ttN/A/ttbr / + a href=directive-dict.html#Context +rel=HelpstrongContext:/strong/a Allowed in *.conf anywhere and in +.htaccessbr / + a href=directive-dict.html#Override +rel=HelpstrongOverride:/strong/a Any other than Nonebr / + a href=directive-dict.html#Status +rel=HelpstrongStatus:/strong/a Extensionbr / + a href=directive-dict.html#Module +rel=HelpstrongModule:/strong/a mod_perl/p +hr / + +h2a id==pod name==pod=pod directive/a/h2 + +pDescription: Start of PODbr / +br / + a href=directive-dict.html#Syntax +rel=HelpstrongSyntax:/strong/a =pod emRaw Text/em +(RAW_ARGS)br / + a
