Re: Possible Apache::AuthenSmb Mod?
Peter Hartzler wrote: Hello, We're looking into using your Apache::AuthenSmb module to allow us to migrate our intranet to GNU/Linux/Apache. One issue we have is that we have two NT domains. I have a couple of different ideas for how to modify the code to allow this scenario, and am wondering if you have any thoughts on this, or would be interested in a patch, or have a patch, or this is already possible and somehow I've missed it... There are a couple of obvious considerations, such as the possibility of userid duplication in the two domains (we don't do that), the need to not break existing/legacy configurations, and perhaps the desirability of passing the user's domain to the script (not sure about that one). Anyhow, thanks for the very useful code, and do feel welcome to jump in if anything moves you! Best Regards, Pete. Hi! I think that Apache-AuthenNTLM may fit the bill for you. Check it out at: http://search.cpan.org/author/SPEEVES/Apache-AuthenNTLM-2.04/AuthenNTLM.pm You are able to create mappings for more than one domain. Also, please include the modperl mailing list in your replies. (This email may have information that will help others in the future :) ) thanks, speeves cws
Apache::ProxyRewrite possible bug with port numbers on ProxyRewrite
I've been kicking around a proxy server here and found your Apache-ProxyRewrite most useful but I have this quirk perhaps you can help with. I'm using version 0.17. I've read in the ChangeLog that one of the more recent fixes (v0.16) may have been to address the problem I'm encountering. Seems as though the ProxyTo doesn't have any trouble with http://host:12345 and the automatic mappings with the same host:port. The ProxyRewrite on the other hand doesn't work with host:port. It's as if the pattern matching goes out to lunch, gets amnesia.. something. I've also noticed that if I have multiple ProxyRewrite statements the last one (provide there's no port number) is the only one being processed. Thanks! Dwayne * * Dwayne Turley, Sr. System Administrator, Code 589 (Wallops) * Real Time Software Engineering Branch * Building N161, Wallops Island VA 23337 * Phone: 757 824 1135 Fax: 757 824 1903 * mailto:[EMAIL PROTECTED] * We all know Linux is great...it does infinite loops in 5 seconds. -- Linus Windows: Where do you want to go today? MacOS: Where do you want to be tomorrow? Linux: Are you coming or what? Windows is not the answer. Windows is the question. No, is the answer.
RE: Possible bug using NTLMv2 across trusted domains.
Hi, 1 - You must be aware, by now, that your machine is infected. Please install and run a recented/updated antivirus. The fact that your question contained a virus is a good reason why nobody answered it. 2 - This list is for mod_perl questions; asking about a particular module is OT (Off-Topic) and that's another reason why nobody answered. 3 - Even if it was on topic, you're testing with *very* old service packs. If you, absolutely, must use an old service pack, then please tell us why; The question is, maybe it's not a bug on the NTLM2 module - but a bug on Windows NT itself, eventualy corrected in SP6a. This is the final reason why your question will remain... unanswered. So, please install both SP6a and the post-sp6a security rollup package on the Windows NT machines, and then contact the module author (or whatever procedures for bug reporting are in the module documentation). Regards, Paulo Meireles -Mensagem original- De: Kevin [mailto:[EMAIL PROTECTED] Enviada: segunda-feira, 7 de Julho de 2003 17:38 Para: undisclosed-recipients: Assunto: Possible bug using NTLMv2 across trusted domains. I believe I have found a problem with NTLMv2 authentication across trusted domains. the setup: DomainA (PDC-A and BDC-A both SP4) DomainB (PDC-B and BDC-B both SP4) Two-way trust exists between DomainA and DomainB client machine (Client1) tested with both SP4 SP5 resides in DomainA When I add the value LMCompatibilityLevel in HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\LSA and set it at 3 (send NTLMv2 response only) everyth@
inline mod_perl - is this possible?
Hi,
I want to do this (serverside of course); is it
possible?
html
I am running
!#perl
print $ENV{MOD_PERL};
print process ID $$;
/!#perl
on Apache!!
/html
What modules/config/etc do I need to set up?
Chris.
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
Re: inline mod_perl - is this possible?
Hi!
On Wed, Mar 19, 2003 at 03:55:20AM -0800, www.ReadNotify.com wrote:
I want to do this (serverside of course); is it
possible?
html
I am running
!#perl
print $ENV{MOD_PERL};
print process ID $$;
/!#perl
on Apache!!
/html
What modules/config/etc do I need to set up?
There are various templating system / app servers on CPAN that let you do
this. Take a look at (e.g.) Mason or Embperl.
There is also Perrin Harkins article on Choosing a Templating System that
describes those (and other) systems;
http://perl.apache.org/docs/tutorials/tmpl/comparison/comparison.html
http://www.masonhq.com/
What Is Mason?
Mason is a powerful Perl-based web site development and delivery engine.
With Mason you can embed Perl code in your HTML and construct pages from
shared, reusable components.
http://perl.apache.org/embperl/
Embperl is a framework for building websites with Perl. For the beginner
it's an easy to setup and use way of embedding Perl code in HTML pages. It
delivers several features that ease the task of creating a websites,
including dynamic tables, formfield-processing, escaping/unescaping, session
handling, caching and more.
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: inline mod_perl - is this possible?
www == www ReadNotify com [EMAIL PROTECTED] writes:
www html
www I am running
www !#perl
www print $ENV{MOD_PERL};
www print process ID $$;
www /!#perl
www on Apache!!
www /html
www What modules/config/etc do I need to set up?
Either Mason or Template Toolkit would probably do. I prefer the latter.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: inline mod_perl - is this possible?
Hi,
Apache::ASP also works very fine:
http://www.apache-asp.org/
Helmut
--On Wednesday, March 19, 2003 03:55:20 -0800 www.ReadNotify.com
[EMAIL PROTECTED] wrote:
Hi,
I want to do this (serverside of course); is it
possible?
html
I am running
!#perl
print $ENV{MOD_PERL};
print process ID $$;
/!#perl
on Apache!!
/html
What modules/config/etc do I need to set up?
Chris.
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
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
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: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
The logic here is simpler: 1. store the new status code (just in case the script has changed it) 2. reset the status code to the one before the script execution 3. if the script has attempted to change the status by itself and the execution status is Apache::OK return that new status. Otherwise return the execution status (which will be either Apache::OK or Apache::SERVER_ERROR) this is different that how Apache::Registry in 1.0 handles it, specifically under circumstances like redirects, where people typically do $r-headers_out(Location = '/foo'); $r-status(REDIRECT); return REDIRECT; what you're saying now is that the status is only propagated if you return OK. (at least that's what I _think_ you're saying - I'm still trying to get back after a week off :) the logic should probably be something like respect the execution status if it is OK or it matches the new status, making $r-status(REDIRECT); return OK; and $r-status(REDIRECT); return REDIRECT; both valid ways to effectively redirect the request from Registry. the $r-status() bit was always a hack - nobody is supposed to fiddle with $r-status, which is why mod_perl saves and restores it. we could do with a better way that saved us from all this logic for people who want to use Registry with the mod_perl API. perhaps a version of the Cooker that simply respected (and expected) the script to return a meaningful status code. thus, the script would return SERVER_ERROR if $@ is true, and the return status of the subroutine otherwise. of course, we can't do this in CGI-portable mode, but for folks that want to use Registry as a dispatch mechanism, this is really the preferred way. --Geoff
Re: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
Geoffrey Young wrote: The logic here is simpler: 1. store the new status code (just in case the script has changed it) 2. reset the status code to the one before the script execution 3. if the script has attempted to change the status by itself and the execution status is Apache::OK return that new status. Otherwise return the execution status (which will be either Apache::OK or Apache::SERVER_ERROR) this is different that how Apache::Registry in 1.0 handles it, specifically under circumstances like redirects, where people typically do $r-headers_out(Location = '/foo'); $r-status(REDIRECT); return REDIRECT; what you're saying now is that the status is only propagated if you return OK. (at least that's what I _think_ you're saying - I'm still trying to get back after a week off :) the logic should probably be something like respect the execution status if it is OK or it matches the new status, making $r-status(REDIRECT); return OK; and $r-status(REDIRECT); return REDIRECT; both valid ways to effectively redirect the request from Registry. the $r-status() bit was always a hack - nobody is supposed to fiddle with $r-status, which is why mod_perl saves and restores it. we could do with a better way that saved us from all this logic for people who want to use Registry with the mod_perl API. perhaps a version of the Cooker that simply respected (and expected) the script to return a meaningful status code. thus, the script would return SERVER_ERROR if $@ is true, and the return status of the subroutine otherwise. of course, we can't do this in CGI-portable mode, but for folks that want to use Registry as a dispatch mechanism, this is really the preferred way. 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. __ 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)
Stas Bekman wrote: Geoffrey Young wrote: The logic here is simpler: 1. store the new status code (just in case the script has changed it) 2. reset the status code to the one before the script execution 3. if the script has attempted to change the status by itself and the execution status is Apache::OK return that new status. Otherwise return the execution status (which will be either Apache::OK or Apache::SERVER_ERROR) this is different that how Apache::Registry in 1.0 handles it, specifically under circumstances like redirects, where people typically do $r-headers_out(Location = '/foo'); $r-status(REDIRECT); return REDIRECT; what you're saying now is that the status is only propagated if you return OK. (at least that's what I _think_ you're saying - I'm still trying to get back after a week off :) the logic should probably be something like respect the execution status if it is OK or it matches the new status, making $r-status(REDIRECT); return OK; and $r-status(REDIRECT); return REDIRECT; both valid ways to effectively redirect the request from Registry. the $r-status() bit was always a hack - nobody is supposed to fiddle with $r-status, which is why mod_perl saves and restores it. we could do with a better way that saved us from all this logic for people who want to use Registry with the mod_perl API. perhaps a version of the Cooker that simply respected (and expected) the script to return a meaningful status code. thus, the script would return SERVER_ERROR if $@ is true, and the return status of the subroutine otherwise. of course, we can't do this in CGI-portable mode, but for folks that want to use Registry as a dispatch mechanism, this is really the preferred way. 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. The only thing that messed me up was when running a script with mod_cgi, you can return your own status codes and apache will happily go along with it. However, when you run the same script under mod_perl's Apache::Registry, you suddenly get Apache::Registry second guessing the script and adding to the script, something that for (especially) USE_LOCAL_COPY and PARTIAL_CONTENT responses is just wrong. I've just ended up writing my own version of Apache::Registry that always returns OK, which works for my purposes and therefore I'm content. 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?
Re: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
David Dick wrote: [...] The only thing that messed me up was when running a script with mod_cgi, you can return your own status codes and apache will happily go along with it. However, when you run the same script under mod_perl's Apache::Registry, you suddenly get Apache::Registry second guessing the script and adding to the script, something that for (especially) USE_LOCAL_COPY and PARTIAL_CONTENT responses is just wrong. I've just ended up writing my own version of Apache::Registry that always returns OK, which works for my purposes and therefore I'm content. 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? Personally I don't see how is it possible to accomodate everybody in the same handler. Because the requirements are conficting and second guessing is working in 99% but breaks for 1%, causing torn out hairs. Perhaps having two different sub-classes which do things differently is the right way to go. The default should follow the course of the least surprise and accomplish what it was designed for in first place: emulate mod_cgi, while giving the speed benefits. The other sub-class should pitch towards developers that use registry, for scripts which are expected to behave differently from mod_cgi. Looks like that's what we have under mod_perl 1.0. Apache::Registry and Apache::PerlRun/RegistryNG behave differently and one should choose between the two according to their needs. Even though the overall implementation is different for a different reason (make a sub-classable registry). __ 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: Possible bug with a 206 Partial Response
alrightly, back again. The problem is that Apache::Registry will return
a 206, which will trigger the error message. In case there is anyone
out there as daft as me :), the crude delegation-type module below can
solve this problem. Maniacs who see a need to return 204's, etc can
probably extend this to a more general solution. :)
package MyPrefix::Apache::Registry;
use strict;
BEGIN {
use Apache::Registry();
use Apache::Constants qw(:common);
use constant PARTIAL_CONTENT = 206;
}
sub handler {
my ($return) = Apache::Registry::handler(@_);
if ($return == PARTIAL_CONTENT) {
return OK;
} else {
return ($return);
}
}
END { }
1;
Uru
-Dave
Ged Haywood wrote:
Hi again,
On Mon, 3 Feb 2003, David Dick wrote:
not even getting a broken connection. So somehow mod_perl doesn't
_really_ think it's an error.
Check out DEBUGGING in 'perldoc Apache::Registry'.
Apache::Registry won't always return what you'd think it should.
This has snookered more than one in the past...
73,
Ged.
Re: Possible bug with a 206 Partial Response
David Dick wrote:
alrightly, back again. The problem is that Apache::Registry will return
a 206, which will trigger the error message. In case there is anyone
out there as daft as me :), the crude delegation-type module below can
solve this problem. Maniacs who see a need to return 204's, etc can
probably extend this to a more general solution. :)
package MyPrefix::Apache::Registry;
use strict;
BEGIN {
use Apache::Registry();
use Apache::Constants qw(:common);
use constant PARTIAL_CONTENT = 206;
}
sub handler {
my ($return) = Apache::Registry::handler(@_);
if ($return == PARTIAL_CONTENT) {
return OK;
} else {
return ($return);
}
}
END { }
1;
When I've tried to run your test script under ModPerl::Registry
(mp2.0) I was surprised to learn that it worked just fine. So far I
was fixing the porting bugs ;) I've added your test script to the
ModPerl::Registry test suite.
We better fix it in the 1.0 core. But before that we need to be clear of how
the return codes should be handled, because the currect three implementations
all diverge when it comes to handling the return codes/execution status.
In order to simplify the logic, assuming that the script was
successfully executed and inlining some code, the 3 different registry
implementations resemble the following:
Apache::Registry does:
my $old_status = $r-status;
eval { {$cv}($r, @_) };
return $r-status($old_status);
Apache::PerlRun/RegistryNG do:
my $old_status = $r-status;
eval { {$cv}($r, @_) };
$r-status($old_status);
return OK;
ModPerl::RegistryCooker does:
# handlers shouldn't set $r-status but return it
my $old_status = $self-[REQ]-status;
eval { {$cv}($r, @_) };
my $new_status = $self-[REQ]-status;
# only if the script has changed the status, reset to the old
# status and return the new status
return $old_status != $new_status
? $self-[REQ]-status($old_status)
: OK;
If I'm correct both Apache::PerlRun and Apache::Registry will have
problems in certain situations if we agree that ModPerl::Registry has
the correct logic for handling the execution status. If you can tell
otherwise please give me a test script that doesn't work under
ModPerl::Registry.
But in your particular example, Dick, if you configure the
script to run under Apache::RegistryNG, does it work? If not, that's where the
difference between 1.0 and 2.0 lays: ModPerl::Registry doesn't reset status if
it wasn't changed by the script.
__
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: Possible bug with a 206 Partial Response
If I'm correct both Apache::PerlRun and Apache::Registry will have problems in certain situations if we agree that ModPerl::Registry has the correct logic for handling the execution status. If you can tell otherwise please give me a test script that doesn't work under ModPerl::Registry. But in your particular example, Dick, if you configure the I'm presuming that you simply mixed up which is my first name and surname? :) Usually dave is fine. :) script to run under Apache::RegistryNG, does it work? No. If not, that's where the difference between 1.0 and 2.0 lays: ModPerl::Registry doesn't reset status if it wasn't changed by the script. well the ModPerl::Registry behaviour certainly suits my program. :) Uru -dave
Re: Possible bug with a 206 Partial Response
Hi there, On Sun, 2 Feb 2003, David Dick wrote: Got a bit of a weird set of behaviour with a mod_perl Apache::Registry type script. [snip] More information about this error may be available in the server error log.P [snip] Anyone got any ideas? What does it say in the error_log? 73, Ged.
Re: Possible bug with a 206 Partial Response
Good Point. Forgot to mention that the error log is completely empty. :) Ged Haywood wrote: Hi there, On Sun, 2 Feb 2003, David Dick wrote: Got a bit of a weird set of behaviour with a mod_perl Apache::Registry type script. [snip] More information about this error may be available in the server error log.P [snip] Anyone got any ideas? What does it say in the error_log? 73, Ged.
Re: Possible bug with a 206 Partial Response
Hi there, On Sun, 2 Feb 2003, David Dick wrote: Forgot to mention that the error log is completely empty. :) Are you getting core dumps? 73, Ged.
Re: Possible bug with a 206 Partial Response
not even getting a broken connection. So somehow mod_perl doesn't _really_ think it's an error. Ged Haywood wrote: Hi there, On Sun, 2 Feb 2003, David Dick wrote: Forgot to mention that the error log is completely empty. :) Are you getting core dumps? 73, Ged.
Re: Possible bug with a 206 Partial Response
Hi again, On Mon, 3 Feb 2003, David Dick wrote: not even getting a broken connection. So somehow mod_perl doesn't _really_ think it's an error. Check out DEBUGGING in 'perldoc Apache::Registry'. Apache::Registry won't always return what you'd think it should. This has snookered more than one in the past... 73, Ged.
Possible bug with a 206 Partial Response
G'day all,
Got a bit of a weird set of behaviour with a mod_perl Apache::Registry
type script.
HISTORY:
I've been using MD5 digests of the html sent from my scripts as ETags,
hence saving an important bit of bandwidth. Got a little bit carried
away with the success of this project and attempted to handle range
requests as well. Worked fine when running as a CGI script, but blew a
fuse when running as an Apache::Registry script. Stripped the script
down to the basics and the error continued.
I have a script called test.pl which has the following content.
#! /usr/bin/perl -wT
MAIN: {
print _OUT_;
Status: 206 Partial Content
Content-Type: text/html; charset=UTF-8
Content-Length: 11
Content-Range: bytes 0-10/1336
Date: Fri, 31 Jan 2003 09:39:01 GMT
ETag:
_OUT_
print '?xml versi';
}
When the script is run, the following output appears.
[dave@localhost]$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /test.pl HTTP/1.1
Host: localhost
HTTP/1.1 206 Partial Content
Date: Sat, 01 Feb 2003 22:12:47 GMT
Server: Apache
Content-Range: bytes 0-10/1336
ETag:
Content-Length: 11
Content-Type: text/html; charset=UTF-8
?xml versi!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
HTMLHEAD
TITLE206 Partial Content/TITLE
/HEADBODY
H1Partial Content/H1
The server encountered an internal error or
misconfiguration and was unable to complete
your request.P
Please contact the server administrator,
[EMAIL PROTECTED] and inform them of the time the error occurred,
and anything you might have done that may have
caused the error.P
More information about this error may be available
in the server error log.P
/BODY/HTML
Fairly obviously, not what is desired. However, if you change the '206'
in the script to a '200', the script works fine. I've searched through
the mod_perl code in a brief fashion for a condition that would cause
this, but couldn't find anything. Anyone got any ideas?
CONFIGURATION
apache 1.3.27
mod_perl 1.27
mod_ssl 2.8.11-1.3.27
httpd.conf
ServerType standalone
ServerTokens ProductOnly
Timeout 300
KeepAlive On
KeepAliveTimeout 100
MaxKeepAliveRequests 10
MinSpareServers 5
MaxSpareServers 10
StartServers 5
MaxClients 20
MaxRequestsPerChild 10
BindAddress 127.0.0.1
Port 80
User nobody
Group nobody
UseCanonicalName On
DefaultType text/plain
HostnameLookups Off
ServerSignature Off
ServerAdmin [EMAIL PROTECTED]
DocumentRoot /path/to/script/parent
VirtualHost *
ErrorLog /var/log/httpd/error_log
Directory /
SetHandler perl-script
PerlHandler Apache::Registry
PerlSendHeader On
/Directory
/VirtualHost
Re: Question on possible effects of mod_perl on mod_cgi
That was it. I redefined Sig{__WARN__} to drop all STDERR output and my
script output everything it was supposed to and exited cleanly. Now
there is another bug that undoubtedly came from my trying to track down
the original issue...
Thanks. That saved me a ton of time.
Tom
Terra Info wrote:
Ugh! I checked the users list archives but I never checked the dev
archives. I liked p5p back in the day because it was all one in the
same. Chaos, but oddly efficient. Thanks for the pointer.
As for the docs, I freely admit I missed it. I was not looking for
PerlRun stuff when I went through that migration piece (I was looking
for a different project) so when I started dealing with this I did not
remember seeing it, therefore in my warped mind it did not exist.
Right now, int/0 looks perfectly fine to me. Anyhow, I doubt listing
all of them would help, just add in Apache::PerlRun into the header so
it reads The Apache::Registry and Apache::PerlRun Families (or ~)
and that would get people's attention a little bit better.
Thanks,
Tom
Stas Bekman wrote:
OK, now it's clear, thanks for the explanation. FWIW, there were
discussions of possible pipes read/write deadlocks in the current
mod_cgi implementation in Apache 2.0, so you may experience just
that. Check the httpd-dev list archives.
[...]
* Given that, I noticed PerlRun was no longer prominintly displayed
in the docs
What made you think so? The PerlRun docs weren't touched for ages.
and the migration FAQ did not to my knowledge even touch on it.
Because all you have to do is to s/Apache::/ModPerl::/ for all
registry handlers, which includes PerlRun. Do you think that it'll
help to explicitly list them 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
--
-
Terra Novum Research
[EMAIL PROTECTED]
www.terranovum.com
(617) 923-4132
PO Box 362
Watertown, MA 02471-0362
They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety.
Benjamin Franklin,
Historical Review of Pennsylvania, 1759
Question on possible effects of mod_perl on mod_cgi
I am debugging a particularly nasty issue right now on a perl script that when written 2+ yrs ago worked fine. NB: It does not run under mod_perl and it has not been modified since then. I run it from the cmd line (with the identical query string and all referenced %ENV vars set identical as well) and it runs fine. I run it as a typical CGI and it has problems that, in *some* ways, mirror the behavior of a poorly written (symptoms associated with unscoped globals, etc;) perl app under mod_perl. And since this is a poorly written app I am curious. Is there any link between mod_perl (1.99..) and mod_cgi (Apache 2)? Does mod_perl in anyway influence or maybe cause PerlRun like caching under mod_cgi? I am just trying to eliminate all possibilities as this one has been a real PITFA. Thanks, Tom
Re: Question on possible effects of mod_perl on mod_cgi
[When starting a new thread, please remember to create a new mail, rather than doing a reply to one of the threads. If you don't do that, your mail software attaches reference ids to the original thread and your post gets folded into the thread you've replied to. people may delete the whole thread without seeing your post if they weren't interested in this thread. it also has an ill effect on mail archives.] Terra Info wrote: I am debugging a particularly nasty issue right now on a perl script that when written 2+ yrs ago worked fine. NB: It does not run under mod_perl and it has not been modified since then. You mean, it has never worked under mod_perl 1.0? Can you test it with mod_perl 1.0? I run it from the cmd line (with the identical query string and all referenced %ENV vars set identical as well) and it runs fine. I run it as a typical CGI and it has problems that, in *some* ways, mirror the behavior of a poorly written (symptoms associated with unscoped globals, etc;) perl app under mod_perl. And since this is a poorly written app I am curious. Is there any link between mod_perl (1.99..) and mod_cgi (Apache 2)? Does mod_perl in anyway influence or maybe cause PerlRun like caching under mod_cgi? I am just trying to eliminate all possibilities as this one has been a real PITFA. You can turn the debugging on and see whether it gets cached. in ModPerl::RegistryCooker set: use constant DEBUG = 4; restart the server and watch error_log, compare the output of Registry with PerlRun. __ 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: Question on possible effects of mod_perl on mod_cgi
The threads issue is my bag. I know better but was busy and distracted,
hence I just did a reply to all and trimmed out the excess. Anyhow, I
think you may have misunderstood my question. Although I have a specific
issue at hand, my question was more generic. My questions are more
related to the overall design of mod_perl and its effects on the
functioning of Apache's other components. Anyhow, in answer to your
question, I have not tried it under mod_perl 1 or 2 because this script
would never function under them. It is that poorly written.
So, is there any link between mod_perl (1.99..) and mod_cgi (Apache 2)?
Does mod_perl in anyway influence or maybe cause PerlRun like caching
under mod_cgi? I realize the answers are probably no but I am at my wits
end with this bug and am trying to elminate things as causes that
normally I would not even think were related.
So you have a better handle on why I am asking, I have a script that
runs fine from the cmd line under all parameter combinations, runs fine
in most situations under CGI but when a few param combinations occur it
fails to execute to completion. The odd thing is the place it hangs up
is the line before exit;. I added a warn('foo at line nnn') after every
line and it warns all they way to the line for exit; but never exists
and apache tells me that the script times out. That combined with the
fact that the script, when executed on the command line, under a faked
up ENV that matches exactly what it gets from httpd runs flawlessly and
to completion, seems to suggest something is happening in the in-process
handling of the CGI script. Does that problem lie in mod_cgi, perl or in
some funky interaction between components? With some of the symptoms I
saw I wanted to rule out mod_perl before I went any further.
Thanks and I hope this made it more clear what I was looking for and why,
Tom
Stas Bekman wrote:
[When starting a new thread, please remember to create a new mail,
rather than doing a reply to one of the threads. If you don't do that,
your mail software attaches reference ids to the original thread and
your post gets folded into the thread you've replied to. people may
delete the whole thread without seeing your post if they weren't
interested in this thread. it also has an ill effect on mail archives.]
Terra Info wrote:
I am debugging a particularly nasty issue right now on a perl script
that when written 2+ yrs ago worked fine. NB: It does not run under
mod_perl and it has not been modified since then.
You mean, it has never worked under mod_perl 1.0? Can you test it with
mod_perl 1.0?
I run it from the cmd line (with the identical query string and all
referenced %ENV vars set identical as well) and it runs fine. I run
it as a typical CGI and it has problems that, in *some* ways, mirror
the behavior of a poorly written (symptoms associated with unscoped
globals, etc;) perl app under mod_perl. And since this is a poorly
written app I am curious. Is there any link between mod_perl (1.99..)
and mod_cgi (Apache 2)? Does mod_perl in anyway influence or maybe
cause PerlRun like caching under mod_cgi? I am just trying to
eliminate all possibilities as this one has been a real PITFA.
You can turn the debugging on and see whether it gets cached.
in ModPerl::RegistryCooker set:
use constant DEBUG = 4;
restart the server and watch error_log, compare the output of Registry
with PerlRun.
__
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
--
-
Terra Novum Research
[EMAIL PROTECTED]
www.terranovum.com
(617) 923-4132
PO Box 362
Watertown, MA 02471-0362
In time-keeping, in trading, in fighting, men counted numbers;
and finally, as the habit grew, only numbers counted.
Lewis Mumford
Re: Question on possible effects of mod_perl on mod_cgi
Terra Info wrote:
The threads issue is my bag. I know better but was busy and distracted,
hence I just did a reply to all and trimmed out the excess.
No prob. the comment was addressed to all subscribers.
Anyhow, I
think you may have misunderstood my question. Although I have a specific
issue at hand, my question was more generic. My questions are more
related to the overall design of mod_perl and its effects on the
functioning of Apache's other components. Anyhow, in answer to your
question, I have not tried it under mod_perl 1 or 2 because this script
would never function under them. It is that poorly written.
I meant the Apache::PerlRun from mod_perl 1.0. Obviously I wasn't trying
to suggest for you to run it as a pure handler ;)
Notice that ModPerl::PerlRun and others aren't exactly the same as their
1.0 counterparts. Due to the threading issues, currently 2.0's registry
aren't chdir()'ing to the scripts directory. That may change in the
future. But this may be unrelated to your problem.
So, is there any link between mod_perl (1.99..) and mod_cgi (Apache 2)?
No.
Does mod_perl in anyway influence or maybe cause PerlRun like caching
under mod_cgi?
The two has nothing to do with each other.
I realize the answers are probably no but I am at my wits
end with this bug and am trying to elminate things as causes that
normally I would not even think were related.
So you have a better handle on why I am asking, I have a script that
runs fine from the cmd line under all parameter combinations, runs fine
in most situations under CGI but when a few param combinations occur it
fails to execute to completion. The odd thing is the place it hangs up
is the line before exit;. I added a warn('foo at line nnn') after every
line and it warns all they way to the line for exit; but never exists
and apache tells me that the script times out. That combined with the
fact that the script, when executed on the command line, under a faked
up ENV that matches exactly what it gets from httpd runs flawlessly and
to completion, seems to suggest something is happening in the in-process
handling of the CGI script. Does that problem lie in mod_cgi, perl or in
some funky interaction between components? With some of the symptoms I
saw I wanted to rule out mod_perl before I went any further.
Thanks and I hope this made it more clear what I was looking for and why,
I still don't understand you. When do you see the problem? When you run
the script under mod_cgi or mod_perl? I don't understand why do you keep
referring to mod_cgi.
And we are talking about Apache/mod_perl 2.0 here, right?
__
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: Question on possible effects of mod_perl on mod_cgi
Stas Bekman wrote: I still don't understand you. When do you see the problem? When you run the script under mod_cgi or mod_perl? I don't understand why do you keep referring to mod_cgi. And we are talking about Apache/mod_perl 2.0 here, right? No. I am talking about mod_cgi when I say mod_cgi. In short you answered my questions with answers I pretty much expected but I wanted my asumptions valiidated. For that I am grateful. Long answer: Let me state why I was looking (ie; the [il]logic to my thinking) to eliminate mod_perl from the list of of possible reasons why a standard CGI would be failing. * It was a perl CGI. * It was failing in ways that were similar, although not directly alike, ways that poorly written perl apps under mod_perl fail. For example, it would hangup, it would bahave oddly like there were variables set that should have been cleared (ie; unscoped globals). * It was a perl CGI. Hence I know that because of the excellent integration of perl into apache (perl in conf files, etc) as a result of mod_perl, I was looking to see if anyone here on mod_perl's list knew of any interactions, etc that could have spilled over into mod_cgi's handling of perl scripts for instance. * Given that, I noticed PerlRun was no longer prominintly displayed in the docs and the migration FAQ did not to my knowledge even touch on it. I was thiking maybe it had become an automatic thing in mod_cgi for mod_perl enabled httpds to try to speed up perl CGI's by using an in-process perl interpretor instead of backticking it. If that was happening I figured someone here would probably know about it. I posted questions to apache's list but it has been slow going getting people knowledgable about mod_cgi to answer. * There was more (il)logic but I think that should be enough to fill in the holes. Thanks, Tom -- - Terra Novum Research [EMAIL PROTECTED] www.terranovum.com (617) 923-4132 PO Box 362 Watertown, MA 02471-0362 The wireless telegraph is not difficult to understand. The ordinary telegraph is like a very long cat. You pull the tail in New York, and it meows in Los Angeles. The wireless is the same, only without the cat. -- Einstein
Re: Question on possible effects of mod_perl on mod_cgi
OK, now it's clear, thanks for the explanation. FWIW, there were discussions of possible pipes read/write deadlocks in the current mod_cgi implementation in Apache 2.0, so you may experience just that. Check the httpd-dev list archives. [...] * Given that, I noticed PerlRun was no longer prominintly displayed in the docs What made you think so? The PerlRun docs weren't touched for ages. and the migration FAQ did not to my knowledge even touch on it. Because all you have to do is to s/Apache::/ModPerl::/ for all registry handlers, which includes PerlRun. Do you think that it'll help to explicitly list them 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: Question on possible effects of mod_perl on mod_cgi
Ugh! I checked the users list archives but I never checked the dev archives. I liked p5p back in the day because it was all one in the same. Chaos, but oddly efficient. Thanks for the pointer. As for the docs, I freely admit I missed it. I was not looking for PerlRun stuff when I went through that migration piece (I was looking for a different project) so when I started dealing with this I did not remember seeing it, therefore in my warped mind it did not exist. Right now, int/0 looks perfectly fine to me. Anyhow, I doubt listing all of them would help, just add in Apache::PerlRun into the header so it reads The Apache::Registry and Apache::PerlRun Families (or ~) and that would get people's attention a little bit better. Thanks, Tom Stas Bekman wrote: OK, now it's clear, thanks for the explanation. FWIW, there were discussions of possible pipes read/write deadlocks in the current mod_cgi implementation in Apache 2.0, so you may experience just that. Check the httpd-dev list archives. [...] * Given that, I noticed PerlRun was no longer prominintly displayed in the docs What made you think so? The PerlRun docs weren't touched for ages. and the migration FAQ did not to my knowledge even touch on it. Because all you have to do is to s/Apache::/ModPerl::/ for all registry handlers, which includes PerlRun. Do you think that it'll help to explicitly list them 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 -- - Terra Novum Research [EMAIL PROTECTED] www.terranovum.com (617) 923-4132 PO Box 362 Watertown, MA 02471-0362 The wireless telegraph is not difficult to understand. The ordinary telegraph is like a very long cat. You pull the tail in New York, and it meows in Los Angeles. The wireless is the same, only without the cat. -- Einstein
[mp1.0] DESTROY doesn't honor read-only flag (possible bug).
Hello,
We began to encounter some odd segfaults, and after poking through
mod_perl believed that we have found the problem. The DESTROY() function
in Table.xs is not honoring the read only flag in self, which would seem
to be a bug.
For reasons we are still trying to discover (;), it's being called and
asked to delete some sort of shared, read-only object (probably belonging
to Apache?). We only saw this happen intermittently, and under very high
load.
The attached patch was written by Erik Arneson ([EMAIL PROTECTED]).
So, is this an actual bug or is it more likely that we're in some way
horribly abusing mod_perl (or is it both ;)?
Thank you all very much,
_Jesse Williamson ;-};
--- apache_1.3.26/mod_perl-1.27/src/modules/perl/Table.xs.table Tue Dec 10 11:55:24
2002
+++ apache_1.3.26/mod_perl-1.27/src/modules/perl/Table.xs Tue Dec 10 11:57:55
+2002
@@ -112,13 +112,19 @@
PREINIT:
Apache__Table tab;
CODE:
-tab = (Apache__Table)hvrv2table(self);
-if(SvROK(self) SvTYPE(SvRV(self)) == SVt_PVHV)
-safefree(tab);
+if (!SvREADONLY(self)) {
+tab = (Apache__Table)hvrv2table(self);
+if(SvROK(self) SvTYPE(SvRV(self)) == SVt_PVHV)
+safefree(tab);
+}
+else {
+fprintf(stderr, Apache::Table is trying to free READONLY SV at %p\n, self);
+fflush(stderr);
+}
void
FETCH(self, key)
Apache::Table self
const char *key
Possible naming error when extracting mod_perl 2 tarball
Hi, I downloaded the mod-perl 2.0 tarball today from: http://perl.apache.org/dist/mod_perl-2.0-current.tar.gz When I untar'd it: bash-2.03$ tar xf mod_perl-2.0-current.tar It extracted to the following directory: drwxr-x--- 13 software software 512 Jun 21 23:40 mod_perl-1.99_04 I was just wondering if this was correct (i.e mod_perl 2.0 extracting to mod_perl 1.99 directory). After looking at the files it looks like it is mod_perl 2 and therefore just a naming error in the archive - a minor issue, but I thought I would ask. Cheers, Tom
Re: Possible naming error when extracting mod_perl 2 tarball
Tom Hibbert wrote: Hi, I downloaded the mod-perl 2.0 tarball today from: http://perl.apache.org/dist/mod_perl-2.0-current.tar.gz When I untar'd it: bash-2.03$ tar xf mod_perl-2.0-current.tar It extracted to the following directory: drwxr-x--- 13 software software 512 Jun 21 23:40 mod_perl-1.99_04 I was just wondering if this was correct (i.e mod_perl 2.0 extracting to mod_perl 1.99 directory). After looking at the files it looks like it is mod_perl 2 and therefore just a naming error in the archive - a minor issue, but I thought I would ask. That's correct. It'll become mod_perl-2.0.xx when the first production version is released. __ 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
Is it possible to change the browser's address/location URL without Redirect?
Looks like my explanation is too long or too bad.
The simple idea is in page step 1, after the
form action=/step/2 method=post.../form
submitted, I want the browser show something
http://www.example.com/step/1/error, instead of
http://www.example.com/step/2,
if there is a need for user to correct the data submitted.
It might be accomplished by using one of the approaches outlined below, but
I was wondering if there's other way that can save the overhead of the
write/read or resend the data, and the re-process. Probably not much we can
do if the URL displayed in the browser's address/location bar depends only
on the action value of the form submitted, not based on the server response?
Harry
- Original Message -
From: Harry Zhu [EMAIL PROTECTED]
To: mod_perl list [EMAIL PROTECTED]
Sent: Thursday, August 08, 2002 4:22 PM
Subject: Can I change the browser's address/location?
Suppose I have a generic content handler to handle requst
/step/1, /step/2, ..., /step/n
Location /step
SetHandler perl-script
PerlHandler MyHandler
/Location
#MyHandler.pm
package MyHandler;
sub handler {
my $r=shift;
my $step = substr($r-path_info(),1);
#do something before fetch the content
#fetch content: usually include a form that will assign action
/step/($step+1)
}
So if everything goes well, the user will follow through from step 1, step
2, until fnish.
Now if in the #do something ... part, something is wrong, it will
usually
require user go back to the same step, for example, to fill the form
again.
The way my old cgi script does is just generate the form with prefilled
value plus some error message indicate what's wrong. It works ok but the
browser location will show /step/($step+1) while it actually is
/step/$step.
Now that I am working it on mod-perl I thought I should be able to do
something about it. I briefly browsed the 2 mod-perl books (eagle,
cookbook), and could not found a simple solution yet (or I missed it?). I
was think using one of the folowing might work:z
1) save the request data in a temp file and redirect or http-refresh to
/step/$step?$session_id or /step/$step/error?$session_id
Remember the content is dynamic and depend on the input form data, so
simple
redirect may not work.
Looks like Apache will not post the form data when redirect with Location?
2) print a short form with hidden data and assign action=/step/$step/error
then submit right away (onload=form.submit()?)
Does anybody have a simple solution, e.g. without redirect? Is it possible
to change the URI showing in the browser's address/location bar?
I would appreciated if somebody can pointer me to the right direction.
Harry
RE: Is it possible to change the browser's address/location URL without Redirect?
One option:
If there's an erro in form 2,
Save the user's form data in some session variables
Then use a META HTTP-EQUIV=Refresh CONTENT=0; URL=/step2 tag to get the
user's browser to redirect.
Then populate the form with the data and error message you saved in his/her
session object.
There are obviously many other ways to do this... but if you're using some
sort of session data structure, this is probably the easiest way to get it
done.
Shawn
-Original Message-
From: Harry Zhu [mailto:[EMAIL PROTECTED]]
Sent: August 9, 2002 2:26 PM
To: [EMAIL PROTECTED]
Subject: Is it possible to change the browser's address/location URL
without Redirect?
Looks like my explanation is too long or too bad.
The simple idea is in page step 1, after the
form action=/step/2 method=post.../form
submitted, I want the browser show something
http://www.example.com/step/1/error, instead of
http://www.example.com/step/2,
if there is a need for user to correct the data submitted.
It might be accomplished by using one of the approaches
outlined below, but
I was wondering if there's other way that can save the overhead of the
write/read or resend the data, and the re-process. Probably
not much we can
do if the URL displayed in the browser's address/location bar
depends only
on the action value of the form submitted, not based on the
server response?
Harry
- Original Message -
From: Harry Zhu [EMAIL PROTECTED]
To: mod_perl list [EMAIL PROTECTED]
Sent: Thursday, August 08, 2002 4:22 PM
Subject: Can I change the browser's address/location?
Suppose I have a generic content handler to handle requst
/step/1, /step/2, ..., /step/n
Location /step
SetHandler perl-script
PerlHandler MyHandler
/Location
#MyHandler.pm
package MyHandler;
sub handler {
my $r=shift;
my $step = substr($r-path_info(),1);
#do something before fetch the content
#fetch content: usually include a form that will assign action
/step/($step+1)
}
So if everything goes well, the user will follow through
from step 1, step
2, until fnish.
Now if in the #do something ... part, something is wrong, it will
usually
require user go back to the same step, for example, to fill the form
again.
The way my old cgi script does is just generate the form
with prefilled
value plus some error message indicate what's wrong. It
works ok but the
browser location will show /step/($step+1) while it actually is
/step/$step.
Now that I am working it on mod-perl I thought I should be
able to do
something about it. I briefly browsed the 2 mod-perl books (eagle,
cookbook), and could not found a simple solution yet (or I
missed it?). I
was think using one of the folowing might work:z
1) save the request data in a temp file and redirect or
http-refresh to
/step/$step?$session_id or /step/$step/error?$session_id
Remember the content is dynamic and depend on the input
form data, so
simple
redirect may not work.
Looks like Apache will not post the form data when redirect
with Location?
2) print a short form with hidden data and assign
action=/step/$step/error
then submit right away (onload=form.submit()?)
Does anybody have a simple solution, e.g. without redirect?
Is it possible
to change the URI showing in the browser's address/location bar?
I would appreciated if somebody can pointer me to the right
direction.
Harry
Re: Is it possible to change the browser's address/location URL without Redirect?
That what's the approach outlined in 1). I was wondering if that network
trip can be avoided.
Thanks,
Harry
- Original Message -
From: French, Shawn [EMAIL PROTECTED]
To: 'Harry Zhu' [EMAIL PROTECTED];
Sent: Friday, August 09, 2002 11:49 AM
Subject: RE: Is it possible to change the browser's address/location URL
without Redirect?
One option:
If there's an erro in form 2,
Save the user's form data in some session variables
Then use a META HTTP-EQUIV=Refresh CONTENT=0; URL=/step2 tag to get
the
user's browser to redirect.
Then populate the form with the data and error message you saved in
his/her
session object.
There are obviously many other ways to do this... but if you're using some
sort of session data structure, this is probably the easiest way to get it
done.
Shawn
-Original Message-
From: Harry Zhu [mailto:[EMAIL PROTECTED]]
Sent: August 9, 2002 2:26 PM
To: [EMAIL PROTECTED]
Subject: Is it possible to change the browser's address/location URL
without Redirect?
Looks like my explanation is too long or too bad.
The simple idea is in page step 1, after the
form action=/step/2 method=post.../form
submitted, I want the browser show something
http://www.example.com/step/1/error, instead of
http://www.example.com/step/2,
if there is a need for user to correct the data submitted.
It might be accomplished by using one of the approaches
outlined below, but
I was wondering if there's other way that can save the overhead of the
write/read or resend the data, and the re-process. Probably
not much we can
do if the URL displayed in the browser's address/location bar
depends only
on the action value of the form submitted, not based on the
server response?
Harry
- Original Message -
From: Harry Zhu [EMAIL PROTECTED]
To: mod_perl list [EMAIL PROTECTED]
Sent: Thursday, August 08, 2002 4:22 PM
Subject: Can I change the browser's address/location?
Suppose I have a generic content handler to handle requst
/step/1, /step/2, ..., /step/n
Location /step
SetHandler perl-script
PerlHandler MyHandler
/Location
#MyHandler.pm
package MyHandler;
sub handler {
my $r=shift;
my $step = substr($r-path_info(),1);
#do something before fetch the content
#fetch content: usually include a form that will assign action
/step/($step+1)
}
So if everything goes well, the user will follow through
from step 1, step
2, until fnish.
Now if in the #do something ... part, something is wrong, it will
usually
require user go back to the same step, for example, to fill the form
again.
The way my old cgi script does is just generate the form
with prefilled
value plus some error message indicate what's wrong. It
works ok but the
browser location will show /step/($step+1) while it actually is
/step/$step.
Now that I am working it on mod-perl I thought I should be
able to do
something about it. I briefly browsed the 2 mod-perl books (eagle,
cookbook), and could not found a simple solution yet (or I
missed it?). I
was think using one of the folowing might work:z
1) save the request data in a temp file and redirect or
http-refresh to
/step/$step?$session_id or /step/$step/error?$session_id
Remember the content is dynamic and depend on the input
form data, so
simple
redirect may not work.
Looks like Apache will not post the form data when redirect
with Location?
2) print a short form with hidden data and assign
action=/step/$step/error
then submit right away (onload=form.submit()?)
Does anybody have a simple solution, e.g. without redirect?
Is it possible
to change the URI showing in the browser's address/location bar?
I would appreciated if somebody can pointer me to the right
direction.
Harry
Re: Is it possible to change the browser's address/location URL without Redirect?
Hello, HZI was wondering if that network trip can be avoided. The answer is no. You might be able to use JavaScript to do it on certain browsers, but I'm reasonably sure you can't do it on recent IE and Netscape browsers. Why do you want to do this? You could use base href/ or similar if your goal is just to make links are relative to a certain root. 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: Is it possible to change the browser's address/location URL without Redirect?
The question is not about how to make links relative to root. The purpose is to show correctly the user what the step he is at in the process. If no mistake, he would be taken to step 2, but since the data has error and he needs correct it, so I would like the browser indicating he is still in the step 1. Although it's not that important an issue. Did you mean javascript can change the URL text displayed in the (some version of) browser's address/location bar? I know it is used to display text in status. Noemally the use of Javascript to validate the data can almost eliminate the needing of such network trip, but not always. Thanks, Harry - Original Message - From: Andrew Ho [EMAIL PROTECTED] To: Harry Zhu [EMAIL PROTECTED] Cc: mod_perl List Sent: Friday, August 09, 2002 4:40 PM Subject: Re: Is it possible to change the browser's address/location URL without Redirect? Hello, HZI was wondering if that network trip can be avoided. The answer is no. You might be able to use JavaScript to do it on certain browsers, but I'm reasonably sure you can't do it on recent IE and Netscape browsers. Why do you want to do this? You could use base href/ or similar if your goal is just to make links are relative to a certain root. 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: Is it possible to change the browser's address/location URL without Redirect?
It is the browser that controls the URL in the Address bar. So one has to
make another call to get the URL refreshed. If you are worry about the
speed, you may
1) return an error code in case of error
2) in Apache's httpd.conf, config that specific error to display
/step/1/error
A simply redirection does the same job.
Peter
- Original Message -
From: Harry Zhu [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, August 09, 2002 11:26 AM
Subject: Is it possible to change the browser's address/location URL without
Redirect?
Looks like my explanation is too long or too bad.
The simple idea is in page step 1, after the
form action=/step/2 method=post.../form
submitted, I want the browser show something
http://www.example.com/step/1/error, instead of
http://www.example.com/step/2,
if there is a need for user to correct the data submitted.
It might be accomplished by using one of the approaches outlined below,
but
I was wondering if there's other way that can save the overhead of the
write/read or resend the data, and the re-process. Probably not much we
can
do if the URL displayed in the browser's address/location bar depends only
on the action value of the form submitted, not based on the server
response?
Harry
- Original Message -
From: Harry Zhu [EMAIL PROTECTED]
To: mod_perl list [EMAIL PROTECTED]
Sent: Thursday, August 08, 2002 4:22 PM
Subject: Can I change the browser's address/location?
Suppose I have a generic content handler to handle requst
/step/1, /step/2, ..., /step/n
Location /step
SetHandler perl-script
PerlHandler MyHandler
/Location
#MyHandler.pm
package MyHandler;
sub handler {
my $r=shift;
my $step = substr($r-path_info(),1);
#do something before fetch the content
#fetch content: usually include a form that will assign action
/step/($step+1)
}
So if everything goes well, the user will follow through from step 1,
step
2, until fnish.
Now if in the #do something ... part, something is wrong, it will
usually
require user go back to the same step, for example, to fill the form
again.
The way my old cgi script does is just generate the form with prefilled
value plus some error message indicate what's wrong. It works ok but the
browser location will show /step/($step+1) while it actually is
/step/$step.
Now that I am working it on mod-perl I thought I should be able to do
something about it. I briefly browsed the 2 mod-perl books (eagle,
cookbook), and could not found a simple solution yet (or I missed it?).
I
was think using one of the folowing might work:z
1) save the request data in a temp file and redirect or http-refresh to
/step/$step?$session_id or /step/$step/error?$session_id
Remember the content is dynamic and depend on the input form data, so
simple
redirect may not work.
Looks like Apache will not post the form data when redirect with
Location?
2) print a short form with hidden data and assign
action=/step/$step/error
then submit right away (onload=form.submit()?)
Does anybody have a simple solution, e.g. without redirect? Is it
possible
to change the URI showing in the browser's address/location bar?
I would appreciated if somebody can pointer me to the right direction.
Harry
Re: Is it possible to change the browser's address/location URL without Redirect?
Simple redirection does not do the same job, because the /step/1/error
page is not a simple error page - I would like it to reload the same form in
step 1 with the values filled and some message indicating what's to be
correct.
Looks like the network trip (redirect/refresh) can not be avoid. Then the
session mechanism maybe better for the speed since it sends less data.
Harry
- Original Message -
From: Peter Bi [EMAIL PROTECTED]
To: Harry Zhu [EMAIL PROTECTED];
Sent: Friday, August 09, 2002 5:18 PM
Subject: Re: Is it possible to change the browser's address/location URL
without Redirect?
It is the browser that controls the URL in the Address bar. So one has
to
make another call to get the URL refreshed. If you are worry about the
speed, you may
1) return an error code in case of error
2) in Apache's httpd.conf, config that specific error to display
/step/1/error
A simply redirection does the same job.
Peter
- Original Message -
From: Harry Zhu [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, August 09, 2002 11:26 AM
Subject: Is it possible to change the browser's address/location URL
without
Redirect?
Looks like my explanation is too long or too bad.
The simple idea is in page step 1, after the
form action=/step/2 method=post.../form
submitted, I want the browser show something
http://www.example.com/step/1/error, instead of
http://www.example.com/step/2,
if there is a need for user to correct the data submitted.
It might be accomplished by using one of the approaches outlined below,
but
I was wondering if there's other way that can save the overhead of the
write/read or resend the data, and the re-process. Probably not much we
can
do if the URL displayed in the browser's address/location bar depends
only
on the action value of the form submitted, not based on the server
response?
Harry
- Original Message -
From: Harry Zhu [EMAIL PROTECTED]
To: mod_perl list [EMAIL PROTECTED]
Sent: Thursday, August 08, 2002 4:22 PM
Subject: Can I change the browser's address/location?
Suppose I have a generic content handler to handle requst
/step/1, /step/2, ..., /step/n
Location /step
SetHandler perl-script
PerlHandler MyHandler
/Location
#MyHandler.pm
package MyHandler;
sub handler {
my $r=shift;
my $step = substr($r-path_info(),1);
#do something before fetch the content
#fetch content: usually include a form that will assign action
/step/($step+1)
}
So if everything goes well, the user will follow through from step 1,
step
2, until fnish.
Now if in the #do something ... part, something is wrong, it will
usually
require user go back to the same step, for example, to fill the form
again.
The way my old cgi script does is just generate the form with
prefilled
value plus some error message indicate what's wrong. It works ok but
the
browser location will show /step/($step+1) while it actually is
/step/$step.
Now that I am working it on mod-perl I thought I should be able to do
something about it. I briefly browsed the 2 mod-perl books (eagle,
cookbook), and could not found a simple solution yet (or I missed
it?).
I
was think using one of the folowing might work:z
1) save the request data in a temp file and redirect or http-refresh
to
/step/$step?$session_id or /step/$step/error?$session_id
Remember the content is dynamic and depend on the input form data, so
simple
redirect may not work.
Looks like Apache will not post the form data when redirect with
Location?
2) print a short form with hidden data and assign
action=/step/$step/error
then submit right away (onload=form.submit()?)
Does anybody have a simple solution, e.g. without redirect? Is it
possible
to change the URI showing in the browser's address/location bar?
I would appreciated if somebody can pointer me to the right direction.
Harry
RE: possible buget in CGI.pm
From: mike808 [mailto:[EMAIL PROTECTED]] Sent: 24 July 2002 05:54 To: Lincoln Stein; Cope, Greg; [EMAIL PROTECTED] Subject: Re: possible buget in CGI.pm Lincoln, Greg, mod_perl list: The problem appears to be that the -no_xhtml option is only processed in _setup_symbols. This is called only during import() and compile(), and sets $XHTML appropriately. However, $XHTML is reset to 1 in initialize_globals(). _reset_globals() is an alias for this as well. initialize_globals() is called only once in the startup execution (has a comment Make mod_perl happy) of the module. However, _reset_globals is called during new(), and is registered with mod_perl as a cleanup handler. What this means is that after the first execution, the cleanup handler fires and _reset_globals() is called, which calls initialize_globals(), which then sets the global $XHTML to 1. QED. Hi Mike, Thanks for the reply, we had got to a similar point as well (that initialize globals was stomping on it the second time round), but not is as much detail thanks for the explinatoin! Lincon, is this enough to go on? We've munged our install, which is not the ideal solution. Thanks everyone for thier time. Lincon for the module, and Mike for the excellent explinatoin. The list is great, and support like this is an excellent factor in our internal push for more Open Source stuff! Greg snippage This message and any attachment has been virus checked by Pfizer Corporate Information Technology, Sandwich.
possible buget in CGI.pm
Hi All, We are implementing mod_perl here for internal intranet use. We have discovered a possible buglet in CGI.pm. We do not want CGI.pm to return XHTML as it upsets Verity indexing (long story). So in Apache::Registry executed scripts we use: use CGI qw( -no_xhtml ); But on the first invocation it returns normal HTML. On second invocation it ignores this directive and returns XHTML. We started a dev server with -X to confirm this. It would appear CGI resets its globals somewhere. Can someone confirm this? Also is this the right forum for this ? Which bit of the plot have I missed? Some versions: Apache 1.3.26, perl 5.6.1, mod_perl 1.27, CGI 2.81 Thanks, Greg Cope This message and any attachment has been virus checked by Pfizer Corporate Information Technology, Sandwich.
Re: possible buget in CGI.pm
Hi,
* [EMAIL PROTECTED] [EMAIL PROTECTED] [2002-07-23 11:26]:
We are implementing mod_perl here for internal intranet use. We have
discovered a possible buglet in CGI.pm.
We do not want CGI.pm to return XHTML as it upsets Verity indexing
(long story).
So sorry to hear about that.
So in Apache::Registry executed scripts we use:
use CGI qw( -no_xhtml );
But on the first invocation it returns normal HTML. On second
invocation it ignores this directive and returns XHTML. We started a
dev server with -X to confirm this. It would appear CGI resets its
globals somewhere.
Can someone confirm this?
Yes:
From CGI.pm, version 2.81:
35 # Here are some globals that you might want to adjust
36 sub initialize_globals {
37 # Set this to 1 to enable copious autoloader debugging messages
38 $AUTOLOAD_DEBUG = 0;
39
40 # Set this to 1 to generate XTML-compatible output
41 $XHTML = 1;
42
43 # Change this to the preferred DTD to print in start_html()
44 # or use default_dtd('text of DTD to use');
45 $DEFAULT_DTD = [ '-//W3C//DTD HTML 4.01 Transitional//EN',
46 'http://www.w3.org/TR/html4/loose.dtd' ] ;
47
Judging from line 35 you might want to adjust some of those globals.
If you are using CGI in the OO way, you can just subclass CGI:
package My::CGI;
use base qw(CGI);
sub initialize_globals {
CGI::initialize_globals();
$CGI::XHTML = 0;
}
And then:
my $q = My::CGI-new;
Of course, I haven't tested this.
Another option is to call:
CGI-import(-no_xhtml);
at the top of your Registry script, which will be executed every time,
whereas the use CGI qw( -no_xhtml ); is only being called at compile
time.
(darren)
--
You can put a man through school, but you cannot make him think.
-- Ben Harper
RE: possible buget in CGI.pm
-Original Message-
From: darren chamberlain [mailto:[EMAIL PROTECTED]]
Can someone confirm this?
Yes:
Good I'm not mad :-)
From CGI.pm, version 2.81:
35 # Here are some globals that you might want to
adjust
36 sub initialize_globals {
37 # Set this to 1 to enable copious autoloader
debugging messages
38 $AUTOLOAD_DEBUG = 0;
39
40 # Set this to 1 to generate XTML-compatible output
41 $XHTML = 1;
42
43 # Change this to the preferred DTD to print in
start_html()
44 # or use default_dtd('text of DTD to use');
45 $DEFAULT_DTD = [ '-//W3C//DTD HTML 4.01 Transitional//EN',
46
'http://www.w3.org/TR/html4/loose.dtd' ] ;
47
Judging from line 35 you might want to adjust some of those globals.
If you are using CGI in the OO way, you can just subclass CGI:
package My::CGI;
use base qw(CGI);
sub initialize_globals {
CGI::initialize_globals();
$CGI::XHTML = 0;
}
And then:
my $q = My::CGI-new;
Of course, I haven't tested this.
Another option is to call:
CGI-import(-no_xhtml);
at the top of your Registry script, which will be executed every time,
whereas the use CGI qw( -no_xhtml ); is only being called at compile
time.
Lookout has givenup putting the ''s in!. grh
Thanks for those Darren,
With out wishing to be rude, the above are all workarrounds the bug (ie it
should not overide the -no_xhtml pragma), and we've used our own.
The subclssing one was good thou! and I did not know the CGI-import one.
Thanks,
Greg
(darren)
--
You can put a man through school, but you cannot make him think.
-- Ben Harper
This message and any attachment has been virus checked by
Pfizer Corporate Information Technology, Sandwich.
Re: possible buget in CGI.pm
I'm aware of the problem, but I haven't been able to track it down. Any help is welcome. Lincoln On Tuesday 23 July 2002 08:27 am, [EMAIL PROTECTED] wrote: Hi All, We are implementing mod_perl here for internal intranet use. We have discovered a possible buglet in CGI.pm. We do not want CGI.pm to return XHTML as it upsets Verity indexing (long story). So in Apache::Registry executed scripts we use: use CGI qw( -no_xhtml ); But on the first invocation it returns normal HTML. On second invocation it ignores this directive and returns XHTML. We started a dev server with -X to confirm this. It would appear CGI resets its globals somewhere. Can someone confirm this? Also is this the right forum for this ? Which bit of the plot have I missed? Some versions: Apache 1.3.26, perl 5.6.1, mod_perl 1.27, CGI 2.81 Thanks, Greg Cope This message and any attachment has been virus checked by Pfizer Corporate Information Technology, Sandwich.
Re: possible buget in CGI.pm
On Tuesday 23 July 2002 08:27 am, [EMAIL PROTECTED] wrote: We do not want CGI.pm to return XHTML ... So in Apache::Registry executed scripts we use: use CGI qw( -no_xhtml ); But on the first invocation it returns normal HTML. On second invocation it ignores this directive and returns XHTML. We started a dev server with -X to confirm this. It would appear CGI resets its globals somewhere. ... Some versions: Apache 1.3.26, perl 5.6.1, mod_perl 1.27, CGI 2.81 On Tuesday 23 July 2002 12:47 pm, Lincoln Stein wrote: I'm aware of the problem, but I haven't been able to track it down. Any help is welcome. Lincoln, Greg, mod_perl list: The problem appears to be that the -no_xhtml option is only processed in _setup_symbols. This is called only during import() and compile(), and sets $XHTML appropriately. However, $XHTML is reset to 1 in initialize_globals(). _reset_globals() is an alias for this as well. initialize_globals() is called only once in the startup execution (has a comment Make mod_perl happy) of the module. However, _reset_globals is called during new(), and is registered with mod_perl as a cleanup handler. What this means is that after the first execution, the cleanup handler fires and _reset_globals() is called, which calls initialize_globals(), which then sets the global $XHTML to 1. QED. It looks like -nosticky suffers from the same fate as well, and I would venture to guess that all of the variables reset in initialize_globals() are not being set properly according to the values parsed in _setup_symbols(). e.g. $NPH, $NOSTICKY, $DEBUG, $HEADERS_ONCE, etc. I think the 'undef $NPH' in new() was an attempt to address this for that variable. But it still leaves the rest out in the cold. Because _setup_symbols eats the parameters (the options passed in on the 'use' line), there's no way to call it again later in new() since it ran at compile time. One might preserve the options passed in to _setup_symbols() and then have new() call it again with those options to make sure that the new instance retains the options set on the 'use' line. LDS, You might want to separate the option parsing from the autoload magic in _setup_symbols(), and just call the option parsing part with the saved options from the 'use' line in the cleanup handler. Mike808/ -- () Join the ASCII ribbon campaign against HTML email and Microsoft-specific /\ attachments. If I wanted to read HTML, I would have visited your website! Support open standards.
Possible module
I have written a module for one of our clients, and want to know if I should make it available on CPAN. My hope is that others might find it useful. The client had a system where he wanted all incoming requests for a site to have the exact same pages if you asked for anything except index.html. The index.html pages for each site were different, and were generated by him with names like index001.html for domain1.com, index002.html for domain2.com, etc. However, he had so many configured domains that his httpd.conf files were getting huge, and his httpd processes were getting bigger and bigger (this may not be a problem with apache 2, I wouldn't know.) We replaced the default translation handler with a perl one that grabbed the domain and matched it against a tied DB file if index.html was asked for (or just /). If the index wasn't asked for, then we just told apache where the directory was to get the files from. After switching to this system, the httpd processes shrank to 2-3 MB, and the number of sites configured to use this system was something like 100,000 individual domains or so, each sharing every single file except the index files. The regular httpd.conf only handled about 2000 before memory sizes became too big. The system also has handled 1.5 million hits in a day. The module addsa directive to the httpd.conf file: PerlIndexConfig, whichsets the directory the common files are located and the DB file to use for determining the index file locations. All I want to know is: Does anybody think this kind of module is useful enough to be made public? Any feedback would be great. Thanks. Marc Slagle
Re: Possible module
Even without modperl, There's More Than One Way To Do It. I like mod_rewrite for this sort of task. See the examples for Virtual host configurations in the 'Apache URL Rewriting Guide'. If this is all you're using mod_perl for, then mod_rewrite is likely to be a better, slimmer option than mod_perl. If you're using mod_perl regardless, then it really comes down to what tools you feel happiest with. Andrew On 11 Jun 2002, simran wrote: Date: 11 Jun 2002 14:02:59 +1000 From: simran [EMAIL PROTECTED] To: Marc Slagle [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Possible module Hi Marc, Sounds like an interesting module... there is probably benifit in making it public as i can envisage people who sell domains with a use for such a module (to provide a custom website coming soon front page). Did you try using Apache's Mass Virtual Hosting though? And if you did consider that, it would be interesting to know why you didn't end up using it. simran. On Tue, 2002-06-11 at 13:38, Marc Slagle wrote: I have written a module for one of our clients, and want to know if I should make it available on CPAN. My hope is that others might find it useful. The client had a system where he wanted all incoming requests for a site to have the exact same pages if you asked for anything except index.html. The index.html pages for each site were different, and were generated by him with names like index001.html for domain1.com, index002.html for domain2.com, etc. However, he had so many configured domains that his httpd.conf files were getting huge, and his httpd processes were getting bigger and bigger (this may not be a problem with apache 2, I wouldn't know.) We replaced the default translation handler with a perl one that grabbed the domain and matched it against a tied DB file if index.html was asked for (or just /). If the index wasn't asked for, then we just told apache where the directory was to get the files from. After switching to this system, the httpd processes shrank to 2-3 MB, and the number of sites configured to use this system was something like 100,000 individual domains or so, each sharing every single file except the index files. The regular httpd.conf only handled about 2000 before memory sizes became too big. The system also has handled 1.5 million hits in a day. The module adds a directive to the httpd.conf file: PerlIndexConfig, which sets the directory the common files are located and the DB file to use for determining the index file locations. All I want to know is: Does anybody think this kind of module is useful enough to be made public? Any feedback would be great. Thanks. Marc Slagle
RE: schedule server possible?
Steve, How about another process on the same machine that periodically accesses http://localhost/administration/schedule_tick.pl - Garnet Family Friendly Search - http://www.find11.com BidSearch - See how much others are bidding on keywords - http://bidsearch.find11.com -Original Message- From: Lihn, Steve [mailto:[EMAIL PROTECTED]] Sent: Monday, April 29, 2002 11:57 AM To: '[EMAIL PROTECTED]' Subject: schedule server possible? Hi, The Apache 2 Connection handler opens up the possibility of using it for all kinds of protocol servers. However, I have a wild question: Is it possible to use Apache mod_perl for a schedule server? I.e., a server that is self existent. For example, I can use Apache 2 for Telnet, FTP, SMTP, or even Telephony Server. But I will need a thread that processes the backend stuff, such as maintaining the database and message queue (more like a cron). Is this configuration possible? Steve Lihn FIS Database Support, Merck Co., Inc. Tel: (908) 423 - 4441 -- Notice: This e-mail message, together with any attachments, contains information of Merck Co., Inc. (Whitehouse Station, New Jersey, USA) that may be confidential, proprietary copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by e-mail and then delete it. ==
RE: schedule server possible?
What I am thinking is that if we can use Apache 2 to do it. That is, to make Apache's function beyond a request/response model. If this API is not there, I am proposing, if possible, 1. Add an Apache API to call sub init; when starting a thread. 2. Within sub init, it calls an Apache API to disable this thread from receiving request, so that it can be used solely for scheduling purpose. Any thumb up or down on this? Steve Lihn FIS Database Support, Merck Co., Inc. Tel: (908) 423 - 4441 -Original Message- From: Garnet R. Chaney [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 30, 2002 12:46 PM To: Lihn, Steve; [EMAIL PROTECTED] Subject: RE: schedule server possible? Steve, How about another process on the same machine that periodically accesses http://localhost/administration/schedule_tick.pl - Garnet Family Friendly Search - http://www.find11.com BidSearch - See how much others are bidding on keywords - http://bidsearch.find11.com -Original Message- From: Lihn, Steve [mailto:[EMAIL PROTECTED]] Sent: Monday, April 29, 2002 11:57 AM To: '[EMAIL PROTECTED]' Subject: schedule server possible? Hi, The Apache 2 Connection handler opens up the possibility of using it for all kinds of protocol servers. However, I have a wild question: Is it possible to use Apache mod_perl for a schedule server? I.e., a server that is self existent. For example, I can use Apache 2 for Telnet, FTP, SMTP, or even Telephony Server. But I will need a thread that processes the backend stuff, such as maintaining the database and message queue (more like a cron). Is this configuration possible? Steve Lihn FIS Database Support, Merck Co., Inc. Tel: (908) 423 - 4441 -- -- -- Notice: This e-mail message, together with any attachments, contains information of Merck Co., Inc. (Whitehouse Station, New Jersey, USA) that may be confidential, proprietary copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by e-mail and then delete it. == == == -- Notice: This e-mail message, together with any attachments, contains information of Merck Co., Inc. (Whitehouse Station, New Jersey, USA) that may be confidential, proprietary copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please immediately return this by e-mail and then delete it. ==
Re: schedule server possible?
But I will need a thread that processes the backend stuff, such as maintaining the database and message queue (more like a cron). Is this configuration possible? You can do this now. We rely on cron to kick off the job, but all the business logic is in Apache/mod_perl. The advantage of using cron is that it has rich support for scheduling. Rob
RE: schedule server possible?
You can do this now. We rely on cron to kick off the job, but all the business logic is in Apache/mod_perl. How do you use cron to do scheduling, yet calls Apache/mod_perl to do the processing? Consider cron does not exist in Win32, maybe an all-Apache solution will be simpler and more elegant!? --Steve -- Notice: This e-mail message, together with any attachments, contains information of Merck Co., Inc. (Whitehouse Station, New Jersey, USA) that may be confidential, proprietary copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please immediately return this by e-mail and then delete it. ==
Re: schedule server possible?
Lihn, Steve wrote: How do you use cron to do scheduling, yet calls Apache/mod_perl to do the processing? Your cron script just uses LWP to call a module running in mod_perl. Consider cron does not exist in Win32, maybe an all-Apache solution will be simpler and more elegant!? Cron does exist on Win32. It's called Scheduled Tasks. I use it all the time to kick off perl scripts. - Perrin
schedule server possible?
Hi, The Apache 2 Connection handler opens up the possibility of using it for all kinds of protocol servers. However, I have a wild question: Is it possible to use Apache mod_perl for a schedule server? I.e., a server that is self existent. For example, I can use Apache 2 for Telnet, FTP, SMTP, or even Telephony Server. But I will need a thread that processes the backend stuff, such as maintaining the database and message queue (more like a cron). Is this configuration possible? Steve Lihn FIS Database Support, Merck Co., Inc. Tel: (908) 423 - 4441 -- Notice: This e-mail message, together with any attachments, contains information of Merck Co., Inc. (Whitehouse Station, New Jersey, USA) that may be confidential, proprietary copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by e-mail and then delete it. ==
Is 'PerlHandler Apache::Registry MySimplePerlModule' possible?
Hello Is it possible to insert my Set-Cookie headers after a modperl script? for exapmle: httpd.conf ... PerlFreshRestart On PerlModule SetMyCookies PerlFixupHandler SetMyCookies PerlSetVar SessionDataPath /tmp/apache_session PerlSetVar SessionLockPath /tmp/apache_session_lock Alias /modperl /home/czinkos/IMI/apache/modperl Location /modperl PerlModule Apache::Registry SetHandler perl-script PerlHandler Apache::Registry SetMyCookies Options ExecCGI /Location ... /httpd.conf The script is simple. It adds to cookies to the header. e.g. $cookie-bake; I've tried it, but id didn't work. I'd like to add some extra header after everything is done. thanks in advance czinkos
Re: Is 'PerlHandler Apache::Registry MySimplePerlModule' possible?
On Thu, 2002-02-07 at 05:31, Zsolt Czinkos wrote: Hello Is it possible to insert my Set-Cookie headers after a modperl script? for exapmle: httpd.conf ... PerlFreshRestart On PerlModule SetMyCookies PerlFixupHandler SetMyCookies PerlSetVar SessionDataPath /tmp/apache_session PerlSetVar SessionLockPath /tmp/apache_session_lock Alias /modperl /home/czinkos/IMI/apache/modperl Location /modperl PerlModule Apache::Registry SetHandler perl-script PerlHandler Apache::Registry SetMyCookies Options ExecCGI /Location ... /httpd.conf The script is simple. It adds to cookies to the header. e.g. $cookie-bake; I've tried it, but id didn't work. I'd like to add some extra header after everything is done. You should look at the Apache::Filter module which will allow you to do this. Cees
Help ! TCP stream kept open by mod_perl : possible ?
Hello ! I have a project with Apache mod_perl and I don't know it it is able to do it. I am of course beginner and any help is welcomed :-)) I want to do a simple webmail, where the program on the server side KEEP a TCP stream permamently open to the mail server (POP3) for each user/customer while he's using the webmail. (Closed after timeout or at logoff) Is this possible ? Thanks for any suggestion ! And happy new year 2002 to everyone ! Denis Bucher P.S. More details and examples : My webmail could be used like that : At login : - open TCP stream to pop3.horus.ch - USER/PASS - reading emails info (that would be put into an array) - nothing more http://.../webmail.pl?showmails;start=1;end=20 - display all mails between 1 and 20 based on array http://.../webmail.pl?deletemail;uidl=hkjdfhskjh43879 - send DELE 34 on the TCP stream This is easily possible with Java Servlets. If it isn't with perl, it means that mod_perl isn't as powerful. -- Denis Bucher, / [EMAIL PROTECTED] Tél. +41-32-7254111 \ Internet Horus Networks / www.horus.infoFax: +41-32-7254112 \ Services / USA: (206) 888-2335 US Fax: (508) 437-1261 \ Provider
Re: Help ! TCP stream kept open by mod_perl : possible ?
Hi there, On Tue, 1 Jan 2002, Denis Bucher wrote: I have a project with Apache mod_perl and I don't know it it is able to do it. It is able. and any help is welcomed :-)) http://perl.apache.org/guide I want to do a simple webmail, Have you checked out the various packages on CPAN? 73, Ged.
possible error in Eagle book? (was RE: help with $r-headers_in-do()method)
On Fri, 17 Aug 2001, Geoffrey Young wrote:
I've got a question for the mod_perl world about the behavior of the
$r-headers_in-do(sub {...some code...}) method.
code snipped
it probably won't matter, but do() iterates through the table and exits
either when the list is exhausted or the subroutine returns a non-true value
$r-headers_in-do(sub {
$request-header(@_);
#print STDERR header passed: (@_)\n;
1;
});
like the Eagle book does and see if that helps. Otherwise, there might be
something going on internally with Apache where the proxy headers are
stripped. I don't do proxies, so I'm not that familar with the mechanics of
them...
--Geoff
Thanks Geoff. In fact, it did matter, and solved the problem.
In the process, I've found what seems to be a mistake, or at least an
oversight, in the Eagle book... (a good workman and all, I know, but bear with
me)
On page 475, it has do() explained exactly as Geoff stated above,
i.e. that the subroutine reference passed to it must return a true value
or the iteration will stop.
But on page 380, it has the following code as part of example 7-12:
$r-headers_in-do(sub {
$request-header(@_);
});
From what I can see, HTTP::Request-header returns undef when
setting a header value, so while this code isn't strictly incorrect, it
won't pass the full header set, just the first header-value pair.
Is this right? I'm fairly new at this, so if anyone else would mind
checking this out, I'd appreciate it.
Thanks.
-mike
--
Michael Styer [EMAIL PROTECTED]
phone: 020 7603 5723107 Shepherd's Bush Rd
fax: 020 7603 2504 London W6 7LP
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.
Possible bug with ModPerl 1.25 and Escape_uri
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. If i do this my $f=CGI::Cookie-new(-name = 'Ticket', -path='/', -value = $ciphertext ); warn --- $f --- ; return $f; (And i had assigned it into a tmp variable and then 'warned' to the apache-error.log) I get this --- Ticket=RandomIV%1F%BC%B8%0B%2C%408%8E%3Fg%B8%AD%1D%60j%D0O %BDW%DD%29%94%A5%01%5B%99G%00%16r%F6%CF%B6%E5%F7%BB%C1-%FF %D8%B9WjLULA%0D%15%BCAb%BAT%5C%EB%2CQ%3E4b2%B6%BF%84%C5%F7 %83W0pm%25%AC%E77%8F%C8B%BFJN%C0Id%1FI%A6%90%06%29A%93IR%A6%A0 %E8Z%7DM%8B%BAK%7F%84%F5%09F%FF%7F%C3%E3%C4k_%C7%E7%E2%7D8 %EA%DB%11%DFe%7B%C5%F0%E7%95%AC%AD%8B%D8%DBp%B9n%A4Co%A6%F1 %1B%F2%FF%0C%9D%5E%23%EFh1B%83g%07%A6%91%A8F%EBZ%BFUke%808%25T %7D%F5%89Vq%B4%B8%3D%FB%0C%9F%7D%C7%CAM%BA%7B%1Dph%9C%95-%1F %D5%DB%1D%93%E6C%07%C1%F5%FB%7E%27%A7%E3g%CA%1E%10T%94%09%1A %96%E3%5C%01%8E%0A%B3%02%B3%B8%26%F3%11%FDg%02%D2%3B%9E%3CP%19 %AE%2F%89%C9%D7%84%ED%B5%EE%D5l%AE%EF%0BK%DA%3D%F7E%5E%C6 %2BqI%40z%25%03%24%9F%22q%A3%25v%BC%13%AB%DF%1ES%B1RT%20F%BF %FA%DD%3D%9E%20%EE%DE%BE%15e%CA%1Ao%A9%D3%0E%7E%B6%08%B1 %CD%12%1A%7ES; path=/ --- apologies for the largeness of that string, but i wanted to show that it does indeed work as i had planned. Now, i had wanted to get rid off CGI from the mod_perl processes (makes it use jst that bit less memory) and I have converted most of it away, except when i do this (with the same string you will notice) my $t=escape_uri($ciphertext); warn -= Ticket=$t; path=/ =- ; return Ticket=$t; path=/; i get this very nice string instead -= Ticket=RandomIV%1f%bc%b8%0b,@8%8e%3fg%b8%ad%1d%60j%d0O %bdW%dd)%94%a5%01%5b%99G; path=/; =- 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. Any pointers or 'your stupid' are, as always, welcome. Regards and thanks Stef (Apache version is 1.3.17, modperl 1.25)
Segfault question and possible workaround
Hello!
Some help and ideas are once again needed...
I'm quite a newbie with mod_perl, so there may be a totally
reasonable explanation to segfaults that follow from a few reloads.
It seems to me that subrequest and/or stat do not work together as
I thought.
##
[Tue May 8 12:32:08 2001] [notice] child pid 1357 exit signal Segmentation fault (11)
##
package Apache::WorkMates::AutoIndex;
use strict;
use Apache::Constants qw(:common DIR_MAGIC_TYPE);
sub handler {
my $r = shift;
return DECLINED unless $r-content_type and $r-content_type eq DIR_MAGIC_TYPE;
$r-send_http_header('text/plain');
opendir DIR, $r-filename;
my @filelist = readdir DIR;
closedir DIR;
foreach my $file (@filelist) {
my $subr = $r-lookup_file($r-filename . '/' . $file);
my $fstat = [ stat $subr-finfo ];
}
$r-print(Kukkuu!);
return OK;
}
1;
##
A very quick check with the following seems to fix it,
but I haven't tested it that much.
foreach ... {
my $real_file = $r-filename . '/' . $file;
my $fstat = [ stat $real_file ];
}
The first code is used in Apache::AutoIndex also, because
my own autoindex owns a lot to Philippe M. Chiasson (Thanks Philippe!).
So maybe some Apache::AutoIndex users have got similar segfaults?
Now there is some information about configuration:
##
diff httpd.conf.default httpd.conf
950a951,954
PerlModuleApache::WorkMates::AutoIndex
PerlHandler Apache::WorkMates::AutoIndex
##
gdb /usr/local/wm5/apache/bin/httpd
(gdb) run -X -f /usr/local/wm5/apache/conf/httpd.conf
Starting program: /usr/local/wm5/apache/bin/httpd -X -f
/usr/local/wm5/apache/conf/httpd.conf
Program received signal SIGSEGV, Segmentation fault.
0x8112181 in Perl_dounwind ()
(gdb) bt
#0 0x8112181 in Perl_dounwind ()
#1 0x811249c in Perl_die_where ()
#2 0x80ef440 in Perl_croak ()
#3 0x80fcb93 in Perl_sv_upgrade ()
#4 0x80ce0ad in Perl_gv_init ()
#5 0x80cf184 in Perl_gv_fetchpv ()
#6 0x8091689 in XS_Apache_finfo ()
#7 0x80fba4b in Perl_pp_entersub ()
#8 0x81277b0 in Perl_runops_standard ()
#9 0x80cb7c9 in perl_call_sv ()
#10 0x8084430 in perl_call_handler ()
#11 0x8083bc2 in perl_run_stacked_handlers ()
#12 0x8081fb0 in perl_handler ()
#13 0x809f799 in ap_invoke_handler ()
#14 0x80b40df in process_request_internal ()
#15 0x80b4146 in ap_process_request ()
#16 0x80ab086 in child_main ()
#17 0x80ab241 in make_child ()
#18 0x80ab3bc in startup_children ()
#19 0x80aba2c in standalone_main ()
#20 0x80ac25c in main ()
#21 0x2ab91dcc in __libc_start_main () from /lib/libc.so.6
(gdb)
##
Same compiler for perl, apache and mod_perl.
mod_perl-1.25
=
$WM5DIR/perl/bin/perl Makefile.PL \
PERL_DEBUG=1 \
EVERYTHING=1 \
APACHE_SRC=../$APACHEDIR/src \
DO_HTTPD=1 \
USE_APACI=1 \
APACI_ARGS='--enable-module=rewrite,--enable-module=so'
make make test make install
(make test 100% successful)
apache_1.3.19
=
./configure --prefix=$WM5DIR/apache \
--activate-module=src/modules/perl/libperl.a \
--enable-module=rewrite \
--enable-module=so \
--disable-rule=EXPAT
make
make install
perl5.005_03
Compiled with -Dprefix=/usr/local/wm5/perl -des -Uusrbinperl
perl -V
Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
Platform:
osname=linux, osvers=2.2.19, archname=i686-linux
uname='linux saphire.kas.utu.fi 2.2.19 #1 thu apr 5 15:18:02 est 2001 i686 unknown
'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef useperlio=undef d_sfio=undef
Compiler:
cc='cc', optimize='-O2', gccversion=2.95.2 2220 (Debian GNU/Linux)
cppflags='-Dbool=char -DHAS_BOOL -I/usr/local/include'
ccflags ='-Dbool=char -DHAS_BOOL -I/usr/local/include'
stdchar='char', d_stdstdio=undef, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldbm -ldb -ldl -lm -lc -lcrypt
libc=, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Built under linux
Compiled at May 8 2001 03:04:44
@INC:
/usr/local/wm5/perl/lib/5.00503/i686-linux
/usr/local/wm5/perl/lib/5.00503
/usr/local/wm5/perl/lib/site_perl/5.005/i686-linux
/usr/local/wm5/perl/lib/site_perl/5.005
.
--
Kari Nurmela,
[EMAIL PROTECTED], (02) 333 8847 / (0400) 786 547
middle tier like j2ee only in mod_perl, possible?
I've been experimenting with what's possible in terms of having mod_perl interface with a system of business logic rather than a relational database. ie. I am try to find the find the mod_perl equivalent of Java's EJB tier in the following: (web brower + servlets) --- (ejb) --- (relational dbms) I've searched CPAN. Here are some better candidates: RPC::PlClient/PlServer/Simple, XMLRPC/SOAP, CORBA::ORBit/Mico. The most promising route seems to be a CORBA interface since such objects could be easily used by other systems. The feeling I'm left with is that although these could be used to implement a middle tier, it ain't exactly the playground filled with toys that J2EE has become. So I'm interested... Has anyone had success with implementing a middle tier for mod_perl? What with? And how successful was it? Matthew
Is mod_perl on win32 possible??
Hi again (and thanks to everyone who replied to my last post). Is it at all possible to get mod_perl to work PROPERLY on win32? Using multi-threading? Since win32 can't fork, Apache here uses multi-threading. This actually works very well... except for mod_perl which doesn't use multi-threading itself. This means that if one page takes a long time to deliver, all other requests will have to wait in line! ...making mod_perl unusable. Is it possible to create a multi-threaded mod_perl handler or won't this help? Or does there exist binaries of Apache for win32 that use forking? Or do I have to set up a linus/bsd server... :) thanks, -Kurt.
Re: Is mod_perl on win32 possible??
It is probably possible. ActiveState made PerlEx do it on Windows IIS multithreaded. 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. :) At 04:38 PM 4/27/01 +0200, Kurt George Gjerde wrote: Hi again (and thanks to everyone who replied to my last post). Is it at all possible to get mod_perl to work PROPERLY on win32? Using multi-threading? Since win32 can't fork, Apache here uses multi-threading. This actually works very well... except for mod_perl which doesn't use multi-threading itself. This means that if one page takes a long time to deliver, all other requests will have to wait in line! ...making mod_perl unusable. Is it possible to create a multi-threaded mod_perl handler or won't this help? Or does there exist binaries of Apache for win32 that use forking? Or do I have to set up a linus/bsd server... :) thanks, -Kurt. __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/
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: Apache::Request problem (possible bug)
this was fixed in cvs this past month. check out the archive of the
apreq-dev list (if there is one somewhere) to see the details. basically it
was because using param() to set a variable was calling Apache::Table-set,
which stringifies its arguments. Now it calls Apache::Table-add and does
some undef'ing, allowing you to set multiple values from a ref.
--Geoff
-Original Message--
From: Cees Hek
To: [EMAIL PROTECTED]
Sent: 4/6/01 11:07 AM
Subject: Apache::Request problem (possible bug)
Either I've found a problem with Apache::Request, or I don't know what
I'm
doing :)
Setting variables with $r-param() doesn't seem to work for array
references. ie the following line from the man page doesn't work
correctly
$r-param('foo' = [qw(one two three)]);
When you look at foo afterwards it returns the string 'ARRAY(0x8c04fd8)'
instead of an actual reference to the array.
I have include a basic handler that demostrates this on my machine
(Apache/1.3.17 mod_perl/1.24 perl 5.005_03)
package Apache::Test;
# File: Apache/Test.pm
use strict;
use Apache::Constants qw(:common);
use Apache::Request ();
sub handler {
my $r = new Apache::Request(shift);
$r-content_type('text/html');
$r-send_http_header();
my @list = $r-param('list');
$r-param('newlist' = [qw(one two three)]);
my @newlist = $r-param('newlist');
my $list = join ', ', @list;
my $newlist = join ', ', @newlist;
print "EOM";
HTML
BODY
list - $listBR
newlist - $newlistBR
BR
FORM
SELECT NAME="list" MULTIPLE
OPTIONBlue
OPTIONGreen
OPTIONRed
OPTIONYellow
/SELECT
INPUT TYPE="submit"
/FORM
/BODY
/HTML
EOM
return OK;
}
1;
--
Cees Hek
SiteSuite Corporation
[EMAIL PROTECTED]
Re: Apache::Request problem (possible bug)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
At 1:07 AM +1000 4/7/01, Cees Hek wrote:
$r-param('newlist' = [qw(one two three)]);
my @newlist = $r-param('newlist');
my @newlist = @{$r-param('newlist')};
What you stored was not an array, but a reference to an array.
- --
Kee Hinckley - Somewhere.Com, LLC - Cyberspace Architects
Now Playing - Folk, Rock, odd stuff - http://www.somewhere.com/playlist.cgi
Now Writing - Technosocial buzz - http://commons.somewhere.com/buzz/
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
-BEGIN PGP SIGNATURE-
Version: PGPfreeware 7.0.3 for non-commercial use http://www.pgp.com
iQA/AwUBOs3IhyZsPfdw+r2CEQKJdgCggzcUkVZyshv0FlIon8adiDRqOIwAnRWv
EDOxp/nQOjVxPJRyhd/BydE3
=Eyiy
-END PGP SIGNATURE-
Apache::Request problem (possible bug)
Either I've found a problem with Apache::Request, or I don't know what I'm
doing :)
Setting variables with $r-param() doesn't seem to work for array
references. ie the following line from the man page doesn't work
correctly
$r-param('foo' = [qw(one two three)]);
When you look at foo afterwards it returns the string 'ARRAY(0x8c04fd8)'
instead of an actual reference to the array.
I have include a basic handler that demostrates this on my machine
(Apache/1.3.17 mod_perl/1.24 perl 5.005_03)
package Apache::Test;
# File: Apache/Test.pm
use strict;
use Apache::Constants qw(:common);
use Apache::Request ();
sub handler {
my $r = new Apache::Request(shift);
$r-content_type('text/html');
$r-send_http_header();
my @list = $r-param('list');
$r-param('newlist' = [qw(one two three)]);
my @newlist = $r-param('newlist');
my $list = join ', ', @list;
my $newlist = join ', ', @newlist;
print "EOM";
HTML
BODY
list - $listBR
newlist - $newlistBR
BR
FORM
SELECT NAME="list" MULTIPLE
OPTIONBlue
OPTIONGreen
OPTIONRed
OPTIONYellow
/SELECT
INPUT TYPE="submit"
/FORM
/BODY
/HTML
EOM
return OK;
}
1;
--
Cees Hek
SiteSuite Corporation
[EMAIL PROTECTED]
possible solution for exec cgi SSI in mod_perl
Hi, I am using lots of exec cgi SSI in my site, all the CGI called using exec are written in perl. !--#exec cgi="standardcgi.cgi"-- I want to take advantage of mod_perl for performance, but as I know "exec" will run as mod_cgi , not as mod_perl. Can I use !--#include virtual="modperlscript.pl"-- ? If above will run, will be run as a sub request.. ? Any other better solution to server the page included mod_perl scripts SSI in it, without running the subrequest/new process? Regards, -Surat Singh Bhati
Re: possible solution for exec cgi SSI in mod_perl
If you build modperl with 'perl Makefile.PL EVERYTHING=1' (or, at least with 'PERL_SSI=1', then your server side includes will have an additional option that looks like this: !--#perl sub="DoSomething"-- This will invoke routine 'DoSomething' when this page is expanded. You'll need to pre-load your module with a PerlRequire or PerlModule directive. You could also use Apache::SSI as the handler to do the same type of thing. Many details of how this works in the Eagle book. One warning: mod_perl *must* be built statically for PerlSSI stuff to work -- if you try to build it dynamically, the build tool prints a warning that "PerlSSI disabled in DSO build", or something like that. HTH, Steve On Sun, 25 Feb 2001, Surat Singh Bhati wrote: Hi, I am using lots of exec cgi SSI in my site, all the CGI called using exec are written in perl. !--#exec cgi="standardcgi.cgi"-- I want to take advantage of mod_perl for performance, but as I know "exec" will run as mod_cgi , not as mod_perl. Can I use !--#include virtual="modperlscript.pl"-- ? If above will run, will be run as a sub request.. ? Any other better solution to server the page included mod_perl scripts SSI in it, without running the subrequest/new process? Regards, -Surat Singh Bhati =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-= Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ |
RE: possible solution for exec cgi SSI in mod_perl
Here's another way around it. You could use HTML::Template in place of SSI. Jamie -Original Message- From: Surat Singh Bhati [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 25, 2001 7:28 AM To: [EMAIL PROTECTED] Subject: possible solution for "exec cgi SSI" in mod_perl Hi, I am using lots of exec cgi SSI in my site, all the CGI called using exec are written in perl. !--#exec cgi="standardcgi.cgi"-- I want to take advantage of mod_perl for performance, but as I know "exec" will run as mod_cgi , not as mod_perl. Can I use !--#include virtual="modperlscript.pl"-- ? If above will run, will be run as a sub request.. ? Any other better solution to server the page included mod_perl scripts SSI in it, without running the subrequest/new process? Regards, -Surat Singh Bhati
init handler possible?
Hi, I'm looking for the opposite of a cleanup handler that can be set during runtime under Apache::Registry. For example, in a script running under Apache::Registry, I want to be able to add only: use MyModule; and have some initilization code get registered to run on every subsequent request automatically? I haven't been able to figure out if this is possible, the only thing I can see is adding the subroutine call after the use manually. Any ideas? Cheers, Alex Gossamer Threads Inc. -- Alex KrohnEmail: [EMAIL PROTECTED] Internet Consultant Phone: (604) 687-5804 http://www.gossamer-threads.com Fax : (604) 687-5806 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: possible bug in mod_perl 1.24_01
-Original Message- From: Michael J Schout [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 18, 2000 2:54 PM To: [EMAIL PROTECTED] Subject: Re: possible bug in mod_perl 1.24_01 I should also have mentioned: I am using perl 5.6.0, Linux 2.2.x I have the same config and don't have any problems... however, from the debug output, it looks to me like it is the Include directive that is mucking things up... `@Include' directive is TAKE1, (1 elements) default: iterating over @Include handle_command (Include "/nis.home/mschout/dev/gkgdrs/gkgnsi/conf/httpd.conf"): loading perl module 'Apache'...ok `@Include' directive is TAKE1, (0 elements) default: iterating over @Include perl_section: /Directory `@Include' directive is TAKE1, (0 elements) default: iterating over @Include perl_section: /Directory ...etc are any of your configuration files a directory? 1.3.14 will now recurse through any config files that are directories and process all the files within... maybe that is going awry somehow? I suppose my suggestion might be to start stripping down your config file to something basic and add stuff until the looping starts - not much help, I know, but... --Geoff I used the same perl / os for both apache1.3.12/mod_perl 1.24, and apache 1.3.14/mod_perl 1.24_01. Mike
possible bug in mod_perl 1.24_01
I have had an application working under apache 1.3.12/mod_perl 1.24 for several months now with no problems. I am currently trying to make the jump to apache 1.3.14/mod_perl 1.24_01 (since mod_perl 1.24 will not easily build agains 1.3.14). When I do this, and then try to start apache, it goes into an infinite loop proocessing perl sections. The stack trace from gdb looks like this: #0 0x4010a6a1 in buffered_vfprintf (s=0xfbad2887, format=Cannot access memory at address 0xbf7ff184 ) at vfprintf.c:1736 1736vfprintf.c: No such file or directory. (gdb) bt #0 0x4010a6a1 in buffered_vfprintf (s=0xfbad2887, format=Cannot access memory at address 0xbf7ff184 ) at vfprintf.c:1736 #1 0x40105966 in _IO_vfprintf (s=0x401aea20, format=0x8119d18 "loading perl module '%s'...", ap=0xbf801910) at vfprintf.c:1029 #2 0x4010e027 in fprintf (stream=0x401aea20, format=0x8119d18 "loading perl module '%s'...") at fprintf.c:32 #3 0x806d0c0 in perl_require_module () #4 0x806b40c in perl_section () #5 0x806b231 in perl_section_self_boot () #6 0x8068d8e in perl_cmd_require () #7 0x8081f29 in invoke_cmd () #8 0x80822ac in ap_handle_command () #9 0x806acb7 in perl_handle_command () #10 0x806b826 in perl_section () #11 0x806b231 in perl_section_self_boot () #12 0x8068d8e in perl_cmd_require () #13 0x8081f29 in invoke_cmd () #14 0x80822ac in ap_handle_command () #15 0x806acb7 in perl_handle_command () #16 0x806b826 in perl_section () #17 0x806b231 in perl_section_self_boot () #18 0x8068d8e in perl_cmd_require () #19 0x8081f29 in invoke_cmd () #20 0x80822ac in ap_handle_command () snip a whole bunch of repetitions of steps 15-20 #5889 0x806acb7 in perl_handle_command () #5890 0x806b826 in perl_section () #5891 0x806b231 in perl_section_self_boot () #5892 0x8068c6c in perl_cmd_module () #5893 0x8081f29 in invoke_cmd () #5894 0x80822ac in ap_handle_command () #5895 0x80822f8 in ap_srm_command_loop () #5896 0x80827ed in ap_process_resource_config () #5897 0x8085f28 in include_config () #5898 0x808206c in invoke_cmd () #5899 0x80822ac in ap_handle_command () #5900 0x806acb7 in perl_handle_command () #5901 0x806b043 in perl_handle_command_av () #5902 0x806b9d8 in perl_section () #5903 0x808206c in invoke_cmd () #5904 0x80822ac in ap_handle_command () #5905 0x80822f8 in ap_srm_command_loop () #5906 0x80827ed in ap_process_resource_config () #5907 0x8082e74 in ap_read_config () #5908 0x808a745 in main () #5909 0x400d89cb in __libc_start_main (main=0x808a560 main, argc=4, argv=0xb914, init=0x8062524 _init, fini=0x811741c _fini, rtld_fini=0x4000ae60 _dl_fini, stack_end=0xb90c) at ../sysdeps/generic/libc-start.c:92 And when I run with "MOD_PERL_TRACE=all" I get a whole bunch of output. It starts out like this: perl_parse args: '/dev/null' ...allocating perl interpreter...ok constructing perl interpreter...ok ok running perl interpreter...ok mod_perl: 0 END blocks encountered during server startup loading perl module 'Apache'...loading perl module 'Apache::Constants::Exports'...ok ok loading perl module 'Tie::IxHash'...ok SVt_PV: $Group = `mschout' handle_command (Group mschout): OK SVt_PV: $ServerAdmin = `[EMAIL PROTECTED]' handle_command (ServerAdmin [EMAIL PROTECTED]): OK perl_section: /Location perl_section: /VirtualHost perl_section: /Directory perl_section: /Location perl_section: /Files perl_section: /Files SVt_PV: $ServerRoot = `/nis.home/mschout/httpd' handle_command (ServerRoot /nis.home/mschout/httpd): OK SVt_PV: $User = `mschout' handle_command (User mschout): OK perl_section: /Directory loading perl module 'Apache'...ok loading perl module 'Tie::IxHash'...ok PORTS CONFIGURATION HTTP : 8531 HTTPS: 4531 `@Listen' directive is TAKE1, (2 elements) default: iterating over @Listen handle_command (Listen 8531): OK handle_command (Listen "4531"): OK perl_section: /Location perl_section: VirtualHost _default_:4531 SSLVerifyDepth 10 (OK) Limit=no SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key (OK) Limit=no SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt (OK) Limit=no SSLVerifyClient none (OK) Limit=no SSLEngine on (OK) Limit=no handle_command (SetEnvIf "User-Agent" ".*MSIE.*" "nokeepalive" "ssl-unclean-shutdown"): OK perl_section: /VirtualHost perl_section: /Directory perl_section: /Location perl_section: /Files SVt_PV: $Port = `8531' handle_command (Port 8531): OK perl_section: /Files perl_section: /Directory loading perl module 'Apache'...ok loading perl module 'Tie::IxHash'...ok SVt_PV: $DAVLockDB = `/var/tmp/DAVLock.mschout' handle_command (DAVLockDB /var/tmp/DAVLock.mschout): OK `@Listen' directive is TAKE1, (0 elements) default: iterating over @Listen perl_section: /Location perl_section: /VirtualHost perl_section: /Directory perl_section: /Location perl_section: /Files perl_section: /Files perl_section: /Directory SVt_PV: $DAVMinTimeout = `600' handle_command (DAVMinTimeout 600): OK loading perl module 'Apache'...ok loading perl module 'Tie::IxHash'...ok
Re: possible bug in mod_perl 1.24_01
I should also have mentioned: I am using perl 5.6.0, Linux 2.2.x I used the same perl / os for both apache1.3.12/mod_perl 1.24, and apache 1.3.14/mod_perl 1.24_01. Mike
simplest authorization possible, please
Hi all, I'm not really that lazy, I could probably find out pretty quickly from the excellent guide or the eagle book in my lap right now. It's just that I'm way behind schedule for an application thats due on monday :=) Any time saved will be greatly appreciated, I promised my daughter a biketrip today. Given this: Location /padm SetHandler perl-script PerlHandler Apache::padm /Location What is the fastest/simplest way to add basic authorization? I'm comfortable with hardcoded usernames/passwords in a handler for now. Many, many thanks in advance. -- robert friberg, ensofus ab
Re: simplest authorization possible, please
* Robert Friberg ([EMAIL PROTECTED]) [001007 03:28]: Hi all, I'm not really that lazy, I could probably find out pretty quickly from the excellent guide or the eagle book in my lap right now. It's just that I'm way behind schedule for an application thats due on monday :=) Any time saved will be greatly appreciated, I promised my daughter a biketrip today. Given this: Location /padm SetHandler perl-script PerlHandler Apache::padm /Location What is the fastest/simplest way to add basic authorization? I'm comfortable with hardcoded usernames/passwords in a handler for now. Many, many thanks in advance. There's nothing that says you have to use perl-based authorization just because you're using mod_perl. Doing it the simple apache way -- with htpasswd files -- would also be fine (and ez to setup): Location /padm AuthName "My Auth" AuthType Basic AuthUserFile "/home/httpd/myapp/auth" require valid-user /Location The file /home/httpd/myapp/auth is administered with the 'htpasswd' binary distributed with Apache. The Apache website has more info, examples, etc. Chris -- Chris Winters Senior Internet Developerintes.net [EMAIL PROTECTED] http://www.intes.net/ Integrated hardware/software solutions to make the Internet work for you.
Re: (possible bug) PerlAccessHandler called twice?
On Thu, 28 Sep 2000, Adi wrote: As it turns out, the second call to My::ProxyAccessOnly is an internal redirect ... Is there a logical reason why PerlAccessHandler should be called twice, the because internal_redirects are implemented with subrequests and subrequests run all phases (except post_read_request, content handler and logging)
(possible bug) PerlAccessHandler called twice?
I am using mod_proxy_add_forward to get the correct IP address from the proxy
server, as described in the guide. On my back-end mod_perl server, I want to
limit access only to requests coming from the proxy server. I can't use simple
IP-based access control via mod_access because PerlPostReadRequestHandler runs
before PerlAccessHandler, so $r-remote_addr has already been changed to the
client's IP.
So, I wrote my own PerlAccessHandler that reads $r-notes to see if the request
came from the proxy:
Perl
sub My::ProxyAccessOnly {
my $r = shift;
my $from_proxy = $r-notes("PROXY_REQUEST");
$r-warn("from_proxy = '$from_proxy'");
return FORBIDDEN unless $from_proxy;
return OK;
}
/Perl
PerlAccessHandler My::ProxyAccessOnly
I added a line to Ask's My::ProxyRemoteAddr that sets $r-notes:
Perl
sub My::ProxyRemoteAddr($) {
my $r = shift;
# we'll only look at the X-Forwarded-For header if the requests
# comes from our proxy at localhost
return OK unless $r-connection-remote_ip eq '127.0.0.1';
if (my ($ip) = $r-header_in('X-Forwarded-For') =~ /([^,\s]+)$/) {
$r-notes("PROXY_REQUEST" = 1); #note that this comes from proxy
$r-connection-remote_ip($ip);
$r-warn("set remote ip to $ip");
}
return OK;
}
/Perl
PerlPostReadRequestHandler My::ProxyRemoteAddr
In my log I get, for each request:
[Thu Sep 28 17:02:25 2000] [warn] set remote ip to 192.168.178.13
[Thu Sep 28 17:02:25 2000] [warn] from_proxy = '1'
[Thu Sep 28 17:02:25 2000] [warn] from_proxy = '0'
As it turns out, the second call to My::ProxyAccessOnly is an internal redirect,
because if I add the following line, everything works as expected, and I only
get one log line.
return DECLINED if !$r-is_initial_req;
[Thu Sep 28 17:02:25 2000] [warn] set remote ip to 192.168.178.13
[Thu Sep 28 17:02:25 2000] [warn] from_proxy = '1'
Is there a logical reason why PerlAccessHandler should be called twice, the
second time from within Apache? Also, is there a better way I should go about
accomplishing my desired goal of only allowing proxy-through requests to the
mod_perl server?
-Adi
Re: PerlModule in .htaccess (for auth) faults (possible patch forperl_config.c)
On 22 Aug 2000, Andrew Gideon wrote:
...
My .htaccess file contains:
PerlModule Apache::TAGXSessionAuth
PerlAuthenHandler Apache::TAGXSessionAuth-authen
PerlAuthzHandlerApache::TAGXSessionAuth-authz
After attaching to a child process and getting the segv,
the stack looks like:
(gdb) where
#0 0x107810 in ap_push_array ()
thanks for digging into this andrew.
i think the problem is related to the perl_merge_server_config routine:
#if 0
/* We don't merge these because they're inlined */
mrg-PerlModule = append_arrays(p, add-PerlModule, base-PerlModule);
mrg-PerlRequire = append_arrays(p, add-PerlRequire, base-PerlRequire);
#endif
this means that VirtualHost configs have NULL for both arrays. this is
fine at startup time, since mod_perl only uses the base_server config.
a simple fix is to not push if either is NULL:
Index: src/modules/perl/perl_config.c
===
RCS file: /home/cvs/modperl/src/modules/perl/perl_config.c,v
retrieving revision 1.103
diff -u -u -r1.103 perl_config.c
--- src/modules/perl/perl_config.c 2000/09/26 20:05:22 1.103
+++ src/modules/perl/perl_config.c 2000/09/26 20:59:48
@@ -587,8 +587,11 @@
return NULL;
}
}
-*(char **)push_array(cls-PerlModule) = pstrdup(parms-pool, arg);
+if (cld-PerlModule) {
+*(char **)push_array(cls-PerlModule) = pstrdup(parms-pool, arg);
+}
+
#ifdef PERL_SECTIONS
if(CAN_SELF_BOOT_SECTIONS)
perl_section_self_boot(parms, dummy, arg);
@@ -618,7 +621,9 @@
}
}
-*(char **)push_array(cls-PerlRequire) = pstrdup(parms-pool, arg);
+if (cls-PerlRequire) {
+*(char **)push_array(cls-PerlRequire) = pstrdup(parms-pool, arg);
+}
#ifdef PERL_SECTIONS
if(CAN_SELF_BOOT_SECTIONS)
perl initialization per virtual host... is it possible
Greetings, Is it possible to setup different Initialization per virtual host? so perhaps one: PerlRequire /usr/local/www_sh/conf/startup.pl per virtual host, each different. -Bill Deegan
Re: perl initialization per virtual host... is it possible
Ged, I think you may have misunderstood. I meant a different startup per virtual host, not per child process. Is that possible? -Bill - Original Message - From: "G.W. Haywood" [EMAIL PROTECTED] To: "William Deegan" [EMAIL PROTECTED] Sent: Thursday, September 14, 2000 1:16 PM Subject: Re: perl initialization per virtual host... is it possible Hi there, On Thu, 14 Sep 2000, William Deegan wrote: Is it possible to setup different Initialization per virtual host? so perhaps one: PerlRequire /usr/local/www_sh/conf/startup.pl per virtual host, each different. No, startup.pl is run before the server forks any children. But you can have lots of different servers running on the one machine. Then you could have a proxy which feeds to the appropriate server depending on the URI. Would that do it, or would it be too painful? 73, Ged.
Re: perl initialization per virtual host... is it possible
| I meant a different startup per virtual host, not per child process. It's perfectly ok to specify a PerlRequire for each virtual host or even in .htaccess, but I think that's a dirty habbit to get into. As the complete perl namespace is shared between all your virtual hosts there is really no benifit, just drawbacks: modules required before Apache forks off will result in all childs using a single copy of that module, but required modules after that will load a copy for each child process. Ime
Re: perl initialization per virtual host... is it possible
"William Deegan" [EMAIL PROTECTED] writes: Ged, I think you may have misunderstood. I meant a different startup per virtual host, not per child process. Is that possible? If you're going to do that, say, to stop virtual servers interfering with each other, consider having COMPLETELY different fat servers hidden behind your thin one. -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Apache, mod_perl, MySQL, Sybase hired gun for, well, hire -
Re: perl initialization per virtual host... is it possible
- Original Message - From: "Ime Smits" [EMAIL PROTECTED] To: "William Deegan" [EMAIL PROTECTED] Cc: "G.W. Haywood" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, September 14, 2000 2:26 PM Subject: Re: perl initialization per virtual host... is it possible | I meant a different startup per virtual host, not per child process. It's perfectly ok to specify a PerlRequire for each virtual host or even in .htaccess, but I think that's a dirty habbit to get into. As the complete perl namespace is shared between all your virtual hosts there is really no benifit, just drawbacks: modules required before Apache forks off will result in all childs using a single copy of that module, but required modules after that will load a copy for each child process. When I do that a "SetEnv" in my virtual host doesn't seem to get passed to the startup.pl... Is that the expected behavior? -Bill
Re: mod_perl security :: possible solution
On Thu, 7 Sep 2000, Félix C.Courtemanche wrote: Hi, I have been looking around for some time already about this and here are the 2 solutions I came up with... I would like some comments, especially if you think it would be safe / fast to use. Uhm, did you read the proposed solutions at http://perl.apache.org/guide/multiuser.html Solution #1 (apache solution) ¯ - Use a centralized apache server for all html request, graphics, etc. mod_php and mod_perl disabled on this server - Redirect a certain directory or sub domains to a personalized apache server (on an unprivileged port), running under the client's uid. - That personalized server would be compiled with mod_perl and mod_php, and running with the following apache directives: - RLimitMEM (http_core.c) :: Soft/hard limits for max memory usage per process - RLimitNPROC (http_core.c) :: Soft/hard limits for max number of processes per uid - It would also have the Apache-Watchdog-RunAway perl module installed to kill zombies. That solution would allow the fastest setup (as far as I am concerned) but I am afraid that redirecting the directory to a personalized apache server could generate some problems... I thought of redirect using the [P] flag (proxy) so that the url viewed in the browser stay the same... however, for each queries, 2 httpd process will have to handle it. This may hurt the performances for a web site using a lot of scripts. Nauh, it won't hurt the performance. Almost everybody uses this scenario. See http://perl.apache.org/guide/strategy.html Solution #2 (perl module solution) ¯ - Only use 1 apache server for everyone - Use Apache:SizeLimit (included with mod_perl) (memory watchdog) - Use Apache-watchdog-runaway (same as above) - Use apache:resources for other control - Use Apache:safe and apache:safe:hole to restrict the use of mod_perl... however I may have to fight with it a bit to allow DBI and other similar modules to be used as well That solution appears to be faster for me, but a lot harder to set up and configure. It may involve some programmation, etc. What is your opinion on these... and do you have a better solution? Wich one is the best? I am open for any comments and help... I plan to set up some package or at least a web page to explain to others how to do it once it is working perfectly for me. I noticed that perl security (along with shell security) is one of the worst seucirty/privacy treat in almost all web hosting companies... and I intend to solve this. :) I don't see any security-wise differences between #1 and #2. These are performance issues, where #1 wins in most cases, while #2 is Ok for specific content delivery setups. See the Strategy chapter link above. You still run mod_perl in both setups, so this is the only thing that you have to solve. I've an overdue article in the queue of things that I've to do, that talks about this, mainly based on the multiuser.html chapter and the information I've collected from ISPs a month ago. (Not much though, so if you have some information to share with public and plug the name of your mod_perl ISP service in make sure to contact me.). _ 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://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org
mod_perl security :: possible solution
Hi, I have been looking around for some time already about this and here are the 2 solutions I came up with... I would like some comments, especially if you think it would be safe / fast to use. Solution #1 (apache solution) ¯ - Use a centralized apache server for all html request, graphics, etc. mod_php and mod_perl disabled on this server - Redirect a certain directory or sub domains to a personalized apache server (on an unprivileged port), running under the client's uid. - That personalized server would be compiled with mod_perl and mod_php, and running with the following apache directives: - RLimitMEM (http_core.c) :: Soft/hard limits for max memory usage per process - RLimitNPROC (http_core.c) :: Soft/hard limits for max number of processes per uid - It would also have the Apache-Watchdog-RunAway perl module installed to kill zombies. That solution would allow the fastest setup (as far as I am concerned) but I am afraid that redirecting the directory to a personalized apache server could generate some problems... I thought of redirect using the [P] flag (proxy) so that the url viewed in the browser stay the same... however, for each queries, 2 httpd process will have to handle it. This may hurt the performances for a web site using a lot of scripts. Solution #2 (perl module solution) ¯ - Only use 1 apache server for everyone - Use Apache:SizeLimit (included with mod_perl) (memory watchdog) - Use Apache-watchdog-runaway (same as above) - Use apache:resources for other control - Use Apache:safe and apache:safe:hole to restrict the use of mod_perl... however I may have to fight with it a bit to allow DBI and other similar modules to be used as well That solution appears to be faster for me, but a lot harder to set up and configure. It may involve some programmation, etc. What is your opinion on these... and do you have a better solution? Wich one is the best? I am open for any comments and help... I plan to set up some package or at least a web page to explain to others how to do it once it is working perfectly for me. I noticed that perl security (along with shell security) is one of the worst seucirty/privacy treat in almost all web hosting companies... and I intend to solve this. :) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Félix C.Courtemanche . Head Designer Co-Administrator . Can-Host Networks http://www.can-host.com [EMAIL PROTECTED]
Re: possible?
Vincent Bruijnes wrote: Dear mod_perl users. Is it possible to have an apache with --enable-shared=max and mod_perl statically linked? If yes please tell me how to do, i need mod_perl statically cause otherwise my Apache::ASP won't work. Sincerely Vincent Bruijnes [EMAIL PROTECTED] Yes, I do it in SunOS 5.6, and it should works elsewhere. $ cd mod_perl-1.24 $ perl Makefile.PL \ APACHE_SRC=../apache_1.3.X/src \ DO_HTTPD=1 \ USE_APACI=1 \ PREP_HTTPD=1 \ EVERYTHING=1 \ $ make $ make install $ cd ../apache_1.3.X/src $ ./configure --prefix=/data/apache --activate-module=src/modules/perl/libperl.a --enable-module=all --enable-shared=max --disable-module=auth_db --disable-shared=perl $ make $ make install
possible?
Dear mod_perl users. Is it possible to have an apache with --enable-shared=max and mod_perl statically linked? If yes please tell me how to do, i need mod_perl statically cause otherwise my Apache::ASP won't work. Sincerely Vincent Bruijnes [EMAIL PROTECTED]
Possible mod_perl or ??? bug?
Hi all-
On a totally different subject, I've been experiencing problems with the
interaction between CGI::Carp and Apache::Session. I find that in a
mod_perl context, if I import CGI::Carp before I import Apache::Session,
then I run into the following error:
[Thu Jun 29 13:14:03 2000] [error] (in cleanup) Can't use an undefined
value as a symbol reference at
/apache/perl/lib/site_perl/5.005/Apache/Session/Lock/File.pm line 109.
This happens if I use "PerlModule" in httpd.conf or "use" in the script
to import them. If you reverse the order, importing Apache::Session
before CGI::Carp, then everything's ok! This also only happens under
mod_perl - under a normal CGI context it works just fine. Strange.
The code this is referencing is this:
sub release_all_locks {
my $self= shift;
my $session = shift;
flock($self-{fh}, LOCK_UN); --- line 109
if ($self-{opened}) {
close $self-{fh} || die $!;
}
$self-{opened} = 0;
$self-{read} = 0;
$self-{write} = 0;
}
So something is screwing up the $self that should be passed to
Apache::Session::Lock::File::release_all_locks() by DESTROY(). Since
this only seems to happen when these two modules play together, it's
been difficult for me to try and find what the problem is. Anyone have
any ideas or see a similar thing on their systems? My config is mod_perl
1.24 / Apache 1.3.12 / Solaris 8.
Thanks,
Nate
possible distributed session server
Saw this on Freshmeat today. It looks like it could be useful for handling session data within a cluster, as a low-end alternative to expensive replicated RDBMS stuff. http://www.fault-tolerant.org/recall/ - Perrin
RE: $r-get_handlers bug/oversight? (possible fix)
On Tue, 2 May 2000, Geoffrey Young wrote: ok, for anyone who is interested, I seem to have fixed the problem (maybe)... here's a patch for Apache.xs from yesterday's cvs (and I didn't see any commits since then...) --- Apache.xs.old Tue May 2 14:25:09 2000 +++ Apache.xs Tue May 2 14:26:19 2000 @@ -220,7 +220,7 @@ perl_handler_merge_avs(hook, avcopy); -return newRV_noinc((SV*)avcopy); +return newRV_inc((SV*)avcopy); } now, the implications of this are way over my head, but it seems to work with the test case below just fine (and my other code with which I initially caught the problem). anyway... hmm, that could result in a leak. i'll look into this soon, thanks for the details and patch!
RE: $r-get_handlers bug/oversight? (possible fix)
ok, for anyone who is interested, I seem to have fixed the problem
(maybe)...
here's a patch for Apache.xs from yesterday's cvs (and I didn't see any
commits since then...)
--- Apache.xs.old Tue May 2 14:25:09 2000
+++ Apache.xs Tue May 2 14:26:19 2000
@@ -220,7 +220,7 @@
perl_handler_merge_avs(hook, avcopy);
-return newRV_noinc((SV*)avcopy);
+return newRV_inc((SV*)avcopy);
}
now, the implications of this are way over my head, but it seems to work
with the test case below just fine (and my other code with which I initially
caught the problem). anyway...
HTH
--Geoff
-Original Message-
From: Geoffrey Young [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 01, 2000 4:32 PM
To: '[EMAIL PROTECTED]'
Cc: '[EMAIL PROTECTED]'
Subject: RE: $r-get_handlers bug/oversight?
hi again...
I'm having lots of problems with the get_handlers method...
the following is
reproducible for me under 1.22, 1.23 and the latest cvs using
1.3.12...
---
#!/usr/bin/perl
my $r = shift;
my $list;
my @array = qw('test' 'array');
$r-pnotes(TEST = \@array);
$r-push_handlers(PerlLogHandler = sub {
my $pnotes = $r-pnotes;
foreach my $key (sort keys %$pnotes) {
warn "this is the key $key";
};
});
#$list = $r-get_handlers('PerlLogHandler');
$r-send_http_header('text/plain');
foreach my $key (@$list) {
print "$key\n";
}
print "done!";
---
running as is prints the pnotes keys.
uncommenting the get_handlers method gives:
Attempt to free unreferenced scalar.
and no other output, yet a code reference is visible in the browser...
The other thing is that this only seems to be an issue for
code references -
if I push My::Logger instead of a subroutine, all is fine...
Am I using push_handlers incorrectly, or is get_handlers
mucked up (or can
nobody reproduce this)?
--Geoff
On Tue, 25 Apr 2000, Geoffrey Young wrote:
Hi all...
I've noticed that get_handlers() will return the
enabled handlers
for a PerlPostReadRequestHandler, but not when it is specified as a
PerlInitHandler (either by calling
$r-get_handlers('PerlPostReadRequestHandler') or
$r-get_handlers('PerlInitHandler'). It is the same with
PerlHeaderParserHandler. An oversight?
Also, I can't get anything for PerlCleanupHandlers,
which kinda
makes sense, since Cleanup isn't really a phase, per se (at least
according
to the book). Does it make sense to add this to
get_handlers() as well?
oversight. neither CleanupHandler nor InitHandlers is in the
handler_table in Apache.xs. probably because those
directives were added
after get/set handlers was implemented, and the table was
never updated.
i'll see about fixing that.
Re: possible bug: mod_perl 1.22 (Perl 5.6 / Apache 1.3.12)
Support for strings represented as a vector of ordinals
Literals of the form Cv1.2.3.4 are now parsed as a string composed
of characters with the specified ordinals. This is an alternative, more
readable way to construct (possibly unicode) strings instead of
interpolating characters, as in C"\x{1}\x{2}\x{3}\x{4}". The leading
Cv may be omitted if there are more than two ordinals, so C1.2.3 is
parsed the same as Cv1.2.3.
Strings written in this form are also useful to represent version "numbers".
It is easy to compare such version "numbers" (which are really just plain
strings) using any of the usual string comparison operators Ceq, Cne,
Clt, Cgt, etc., or perform bitwise string operations on them using C|,
C, etc.
In conjunction with the new C$^V magic variable (which contains
the perl version as a string), such literals can be used as a readable way
to check if you're running a particular version of Perl:
# this will parse in older versions of Perl also
if ($^V and $^V gt v5.6.0) {
# new features supported
}
Crequire and Cuse also have some special magic to support such literals.
They will be interpreted as a version rather than as a module name:
require v5.6.0; # croak if $^V lt v5.6.0
use v5.6.0; # same, but croaks at compile-time
Alternatively, the Cv may be omitted if there is more than one dot:
require 5.6.0;
use 5.6.0;
Also, Csprintf and Cprintf support the Perl-specific format flag C%v
to print ordinals of characters in arbitrary strings:
printf "v%vd", $^V; # prints current version, such as "v5.5.650"
printf "%*vX", ":", $addr; # formats IPv6 address
printf "%*vb", " ", $bits; # displays bitstring
See Lperldata/"Scalar value constructors" for additional information.
=head2 Improved Perl version numbering system
Beginning with Perl version 5.6.0, the version number convention has been
changed to a "dotted integer" scheme that is more commonly found in open
source projects.
Maintenance versions of v5.6.0 will be released as v5.6.1, v5.6.2 etc.
The next development series following v5.6.0 will be numbered v5.7.x,
beginning with v5.7.0, and the next major production release following
v5.6.0 will be v5.8.0.
The English module now sets $PERL_VERSION to $^V (a string value) rather
than C$] (a numeric value). (This is a potential incompatibility.
Send us a report via perlbug if you are affected by this.)
The v1.2.3 syntax is also now legal in Perl.
See LSupport for strings represented as a vector of ordinals for more on
that.
To cope with the new versioning system's use of at least three significant
digits for each version component, the method used for incrementing the
subversion number has also changed slightly. We assume that versions older
than v5.6.0 have been incrementing the subversion component in multiples of
10. Versions after v5.6.0 will increment them by 1. Thus, using the new
notation, 5.005_03 is the "same" as v5.5.30, and the first maintenance
version following v5.6.0 will be v5.6.1 (which should be read as being
equivalent to a floating point value of 5.006_001 in the older format,
stored in C$]).
possible bug: mod_perl 1.22 (Perl 5.6 / Apache 1.3.12)
Hi, Please for give if this is a FAQ, but I didn't see it mentioned in the recent list archives. I just upgraded to 5.6, and proceeded to upgrade from mod_perl 1.32_03 to 1.22 (under Apache 1.3.12, using gcc 2.95.1). Everything built fine, but httpd failed to start. The error message was: Apache.pm version 1.26 or higher required! /usr/lib/perl5/site_perl/5.6.0/i686-linux/Apache.pm is only version 1.26 Perhaps you forgot to 'make install' or need to uninstall an old version? Found: /usr/lib/perl5/site_perl/5.6.0/i686-linux/Apache.pm Odd, eh? Since when does 1.26 != 1.26? :-) After trying a bunch of stuff, I realized that the error was coming from mod_perl.c, line 538: if(SvNV(version) = MP_APACHE_VERSION) /*no worries*/ return; After looking up SvNV() to find that it produces a float, I changed line 526 from #define MP_APACHE_VERSION 1.26 to float MP_APACHE_VERSION = 1.26; and now everything is working correctly. What I don't undetrstand is that the original code was identical in mod_perl 1.21, but I didn't have this problem. Could this be due to some internal change in Perl 5.6? -- Dave --- Dave Seidel [EMAIL PROTECTED] www.superluminal.com/dave/
Re: possible bug: mod_perl 1.22 (Perl 5.6 / Apache 1.3.12)
On Tue, 28 Mar 2000, Dave Seidel wrote: and now everything is working correctly. What I don't undetrstand is that the original code was identical in mod_perl 1.21, but I didn't have this problem. Could this be due to some internal change in Perl 5.6? probably, thanks for the fix!
Re: [SITE] possible structure suggestion
Something I'd really love to see, is documentation to the extent that the php site has docs. And thier docs are user-annotatable, which is a really cool feature. -- Matt/ Details: FastNet Software Ltd - XML, Perl, Databases. Tagline: High Performance Web Solutions Web Sites: http://come.to/fastnet http://sergeant.org Available for Consultancy, Contracts and Training.
Re: [SITE] possible structure suggestion
At 11:05 10/02/2000 +0200, Stas Bekman wrote: Please decide whether you want to have the discussion at the mod_perl list or its sister advocacy list. I've added the advocacy list to CC, so at least the person who will search the advocacy archive in the future will find all the info about this important issue. Therefore I quote it in all completeness here. I'm moving it to modperl-advocacy now that I've found out that it exists. TomC, please don't tell me that I don't know how to quote. Thank you! lol :) Well that proves how good he is at getting a message echoed to the entire community. .Robin Earth is a beta site.
