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
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@
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.
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
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.
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.
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: Possible bug with ModPerl 1.25 and Escape_uri
On Fri, 6 Jul 2001, Stef Telford wrote: Hello, I hope this is the right place to put this. I have some code that takes data from a database and encrypts it via Blowfish and CBC. Not a problem so far, the problems comes with sending it to the client. ... Now, if i look at the string (and ignoring all the strange characters that slip through escape_uri) i cant help but notice that escape_uri 'breaks' on the character after %99G which, lo and behold, is %00 which says to me that for some reason CGI::Cookie does the 'right thing' in the case of Blowfish encrypted text, but escape_uri in mod_perl doesnt. looks like apache's uri escape code does not properly handle binary data. one solution would be base64 encode your $ciphertext before using it to create the cookie, then decode it after fetching the cookie. you can use MIME::Base64 for this, which is fairly lightweight.
Re: 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
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
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
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)
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
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$]).
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: possible patch for Apache::AuthCookie
[EMAIL PROTECTED] (Robert Locke) wrote:
Below is a proposed patch to AuthCookie.pm that I believe solves this
problem. Basically, I replaced each occurrence of the above with:
$r-err_headers_out-add("Set-Cookie" = ...
I think you've got the patch backwards.
PS. Who's the current maintainer of Apache::AuthCookie? I seem to
remember reading somehwere that it is no longer Eric Bartley.
Yeah, it's not. I've been toying with the code and improving it, but my
improvements make it non-backward-compatible. So I might need to change
the name and make myself the owner of the new version. Not that I have
a lot of time...
--
diff AuthCookie.pm*
112c112
$r-err_headers_out-add("Set-Cookie" = $auth_type . "_" .
---
$r-err_header_out("Set-Cookie" = $auth_type . "_" .
114c114
$r-log_error("set_cookie " . $r-err_headers_out-add("Set-Cookie"))
---
$r-log_error("set_cookie " . $r-err_header_out("Set-Cookie"))
142c142
$r-err_headers_out-add("Set-Cookie" = $auth_type . "_" . $auth_name .
---
$r-err_header_out("Set-Cookie" = $auth_type . "_" . $auth_name .
145c145
$r-log_error("set_cookie " . $r-err_headers_out-add("Set-Cookie"))
---
$r-log_error("set_cookie " . $r-err_header_out("Set-Cookie"))
--
------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED]The Math Forum
