RAW_ARGS question
Hello. I want my modperl2 module to process RAW_ARGS configuration directives like this. AxMediaType screen AxStyleName #default AxAddProcessor text/xsl /styles/webpage_screen.xsl /AxStyleName AxStyleName printable AxAddProcessor text/xsl /styles/webpage_printable.xsl /AxStyleName /AxMediaType There is no example in the documentation how to implement it, could anybody give me such example? -- Yuriy Sytota
cmd_data analogous
Hello. The command_rec structure in Apache has a useful field named cmd_data. Is there an analogous field in the @APACHE_MODULE_COMMANDS from mod_perl2? -- Yuriy Syrota
Re: Install on s390
Steven A. Adams writes: Has anyone out there installed mod_perl on Linux for s390 (SuSE, RH or Debian)? I'd be very interested in any success stories or gotchas before I start on that journey. SLES8 comes with mod_perl-1.27-28.s390.rpm. I've just installed it on my system but I haven't tried it out yet. Regards, --Malcolm -- Malcolm Beattie [EMAIL PROTECTED] Linux Technical Consultant IBM EMEA Enterprise Server Group... ...from home, speaking only for myself
Re: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
The only thing that puzzles me about this thread is that it seems to be leaning towards the position that says; If the developer just does straight out weird stuff and messes with $r-status in a cgi-script and expects it to work with Apache::Registry (which as far as I understand is a cgi emulation layer), we will accommodate them. However, if the s/he just expects Apache::Registry to behave like it mod_cgi (except faster, more brilliant, etc :)) then they will be disappointed. I am probably just fixated over my current work and can't see the proverbial forest. Can somebody explain this for me? well, Apache::Registry started out as a mod_cgi emulation layer, trying to speed up legacy mod_cgi scripts without alteration. personally, I think that concept is flawed because we all know that many legacy CGI scripts are poorly written, so you need take special measure to not fall into the numerous documented Registry traps. not to mention that Registry doesn't handle HEAD requests properly (in 1.0), if you read POST data elsewhere you're SOL in your CGI script, etc. but, ok, say you have your CGI emulation layer - that's one facet of Registry. however, Registry also acts as a dispatch mechansim for people wanting to use the mod_perl API without writing separate handlers for each bit of functionality - since you get $r passed in automatically, or can retrieve it via Apache-request on your own, you are fully free to use Registry this way and many people do. fiddling with $r-status is _only_ possible when Registry is used in this way - there is no mod_cgi equivalent way to set that part of the request record (that I know about, anyway :) for people who want to use the mod_perl API to, say, return REDIRECT, there needs to be some mechanism to allow them to do so, and the $r-status hack has traditionally served this purpose. (one of) my points before was that with 2.0 and the Cooker idea, we really can (and ought to) have two versions of Registry to accomodate these two needs - people who just want faster mod_cgi (and Registry returns OK or SERVER_ERROR) and people who want the mod_perl API (and Registry returns the script return code). separating out the two classes of users will probably make the Registry logic much easier and cleaner. just my $0.02. --Geoff
Fw: Has Apache::Cookie been ported to mod_perl-2 yet?
Has Apache::Cookie been ported to mod_perl-2 yet? I tried to install the libapreq-1.1 module with mod_perl-2/apache 2 and am getting a can't locate Apache/MyConfig.pm ... error. Charles M.
Re: Disabling TransHandler
Our sysadmin was attempting to disable a TransHandler for a virtual host
using a directive that he used in the past. I wasn't aware of such a
directive and was further stumped when I saw it :
PerlSetVar authsession false
He does not remember where he got this from but it seems to work. Any
ideas as to why this would disable a TransHandler? Where does it come
from and what mod_perl code uses it?
The only TransHandler on this site makes no references to using any
configuration variables set this way.
I suppose you had PerlPostReadRequestHandler which was doing:
my $auth = $r-dir_config('authsession');
$r-set_handlers(PerlTransHandler = sub { return OK })
if $auth eq 'false';
this is not a magic internal feature ;)
Nope, I wrote every handler being used on the system and there is nothing
that uses the 'authsession' directive/variable.
It turns out this variable did nothing ... the trans handler took care of a
simple redirect under certain circumstances which the sys-admin wanted to
avoid. It turns out that some time ago he put an html file containing a
redirect that pointed to where he wanted which the trans handler redirected
to! He just forgot he did this and assumed that the PerlSetVar directive
was what prevented the trans handler from functioning ...
Thanks for the response : )
Simultaneous GET and POST data
Has anyone experienced issues with retrieving data when POSTed by a form whith an action parameter that has a query string attached to it? On rare occasion it seems that the posted data is not available. Apache/1.3.22 (Unix) mod_perl/1.26 mod_ssl/2.8.5 OpenSSL/0.9.6b Mason 1.04 Template Toolkit 2.07
Re: Fw: Has Apache::Cookie been ported to mod_perl-2 yet?
Thanks, is there any word on when this may happen? Charles
Re: Fw: [Perl] how to static link mod_perl 2 into apache 2.0
I'm also running a Mason based system, but I'm sticking with mod_perl-1.0 for now. From the Mason FAQ: (http://www.masonhq.com/docs/faq/#can_i_use_mason_with_mod_perl_1_) Until some time after mod_perl 2.0 is officially released, Mason will only support mod_perl 1.x, specifically 1.22+. You may be able to use Mason with mod_perl 2.0 if you turn on mod_perl 2.0's 1.x compatibility layer by loading ``Apache::compat'' before you load Mason. Hope this helps Casey Songer [EMAIL PROTECTED] Stas Bekman wrote: Issac Goldstand wrote: Forwarding this from another list, because it's more appropriate here :-) - Original Message - *From:* Ron Gidron mailto:[EMAIL PROTECTED] *Sent:* Monday, February 10, 2003 3:48 PM *Subject:* [Perl] how to static link mod_perl 2 into apache 2.0 I am trying to install a Mason based system. This package requires mod_perl statically linked and not as a DSO. for this new installation I decided to test Apache 2.0 and mod_perl 2.0. I downloaded the source for both packages and I am able to configure and make / make test /make install for both without problems however when I issue the command apachectl -l I don't see any reference to mod_perl. I have tried playing with the ./configure options for apache (--enable-perl etc) but nothing seams to get me to where I need to go, this is getting quite frustrating... does anyone have any tips? have any of you installed this configuration before, do you happen to remember the order of steps you took? At this point only DSO is supported by 2.0. What's wrong with using DSO? The package requires mod_perl to be statically linked, but it talks about mod_perl-1.0. I'd first check with Mason folks whether 2.0 is supported at all. __ 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
Re: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
OK, so we are not done with it. The first thing I'd like to see is to have Apache::Registry and Apache::PerlRun agree on how they handle return codes, because they aren't the same. Once this happens, the Cooker will do the same. As you have mentioned we have a problem with relying on return status. Because if the script doesn't use the mod_perl API, it normally may return absolutely anything, which may mess things up. So the safest approach, is to run the script, ignore its return value (not status!) and return OK or SERVER_ERROR based on whether the execution was error-free or not. Plus add the hack of returning of the new status if it was changed by the script. That's the approach that is taken by Apache::Registry and it seems that most people are happy with it. PerlRun does return the execution status, but when I first made the Cooker use this approach we immediately received a bug report, where the script wasn't doing the right thing. I can't remember whether you modeled Cooker after PerlRun or RegistryNG. the current logic in RegistryNG represents a recent change and is my fault http://marc.theaimsgroup.com/?l=apache-modperl-devm=101240123609773w=2 basically, I was trying to fix pretty much what we're talking about but might have gotten it wrong. we probably ought to just follow the 1.0 Registry formula, since I can't remember anybody complaining about it in recent memory. that is, if we're going to have one version - see my other email for thoughts on having two versions of Registry :) --Geoff
Re: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
Geoffrey Young wrote: OK, so we are not done with it. The first thing I'd like to see is to have Apache::Registry and Apache::PerlRun agree on how they handle return codes, because they aren't the same. Once this happens, the Cooker will do the same. As you have mentioned we have a problem with relying on return status. Because if the script doesn't use the mod_perl API, it normally may return absolutely anything, which may mess things up. So the safest approach, is to run the script, ignore its return value (not status!) and return OK or SERVER_ERROR based on whether the execution was error-free or not. Plus add the hack of returning of the new status if it was changed by the script. That's the approach that is taken by Apache::Registry and it seems that most people are happy with it. PerlRun does return the execution status, but when I first made the Cooker use this approach we immediately received a bug report, where the script wasn't doing the right thing. I can't remember whether you modeled Cooker after PerlRun or RegistryNG. the current logic in RegistryNG represents a recent change and is my fault http://marc.theaimsgroup.com/?l=apache-modperl-devm=101240123609773w=2 basically, I was trying to fix pretty much what we're talking about but might have gotten it wrong. we probably ought to just follow the 1.0 Registry formula, since I can't remember anybody complaining about it in recent memory. that is, if we're going to have one version - see my other email for thoughts on having two versions of Registry :) I don't see what's wrong with your change, it brings things to be more consistent with Registry.pm. I've modeled the RegistryCooker after PerlRun.pm/RegistryNG.pm, but referring to Registry.pm when unsure. In any case, let's leave 1.0 alone (those who need it changed, can subclass RegistryNG) and work out a good 2.0. Re: ModPerl::RegistryCooker and its subclasses, you have to come forward and send tests that don't work as expected and we will act accordingly. My goal is to have an exhaustive test suite for registry scripts, because I'm sick of running my in-head built-in mod_perl ;) That includes lots of edge cases, for various error cases and such. Currently we have 34 tests, but more are needed. 206ok 404ok 500ok basic..ok closureok perlrun_requireok redirect...ok special_blocks.ok All tests successful. Files=8, Tests=34, 11 wallclock secs ( 6.80 cusr + 0.80 csys = 7.60 CPU) __ 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
Re: RAW_ARGS question
Yuriy Syrota wrote: Hello. I want my modperl2 module to process RAW_ARGS configuration directives like this. AxMediaType screen AxStyleName #default AxAddProcessor text/xsl /styles/webpage_screen.xsl /AxStyleName AxStyleName printable AxAddProcessor text/xsl /styles/webpage_printable.xsl /AxStyleName /AxMediaType There is no example in the documentation how to implement it, could anybody give me such example? Indeed, there is none, but there is at least one in the mod_perl source, written in C, see: src/modules/modperl_cmd.c:MP_CMD_SRV_DECLARE(perl) and probably a few more in the httpd source. Since you are working on implementing it, if you can contribute such an example to the documentation, that would be grand! Thank you. __ 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
Re: cmd_data analogous
Yuriy Syrota wrote:
Hello.
The command_rec structure in Apache has a useful field named cmd_data.
Is there an analogous field in the @APACHE_MODULE_COMMANDS from
mod_perl2?
Yup, it's called 'data'
src/modules/perl/modperl_module.c:705
/* no default if undefined */
if (!(errmsg = modperl_module_cmd_fetch(aTHX_ obj, data, val))) {
info-cmd_data = apr_pstrdup(p, SvPV(val, len));
}
Since I was porting the existing docs and this field didn't exist in 1.0, I've
missed it.
A documentation patch and a small test (just extend one of the
t/response/TestDirective/perlloadmodule*) is very appreciated.
__
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
Re: Fw: Has Apache::Cookie been ported to mod_perl-2 yet?
Charles O. McElhose Jr. wrote: Thanks, is there any word on when this may happen? Subscribe to the apreq-dev list to stay up to date with the recent developments http://httpd.apache.org/apreq/ meanwhile use CGI::Cookie if you work with mod_perl 2.0. __ 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
Re: Simultaneous GET and POST data
Stathy G. Touloumis wrote: Has anyone experienced issues with retrieving data when POSTed by a form whith an action parameter that has a query string attached to it? On rare occasion it seems that the posted data is not available. Do you use CGI.pm? In versions from 2.xx (81?) up to 2.89 this feature was broken. Apache/1.3.22 (Unix) mod_perl/1.26 mod_ssl/2.8.5 OpenSSL/0.9.6b Mason 1.04 Template Toolkit 2.07 -- Serguei Trouchelle http://www.isd.dp.ua/
