Re: unsetting PerlTransHandler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 14 August 2003 12:34, Frank Maas wrote:
and want to unset the TransHandler inside the Location.
How to do that?
AFAIK: not. The TransHandler is the first to be called and cannot appear
inside a container (ref. ModPerl cookbook). The only thing I can think of,
and in fact implemented this, to make the TransHandler URI-aware and
return immediately if the uri is something you do not want to be touched
by the TransHandler.
Yes, I've implemented it also that way. But I thought Location acts on the
URI and in principle there can be a Location-specific transhandler. I'm
wondering why it is impossible?
For now I have implemented that particular case by
PerlTransHandler MyPackage::transhandler
Location ...
PerlHandler MyPackage::handler
/Location
package MyPackage;
sub transhandler {
...
return DECLINED
if(grep {$_ eq __PACKAGE__.'::handler'} @{$r-get_handlers('PerlHandler')});
...
}
i.e. if my handler is installed return DECLINED.
Torsten
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE/O2e0wicyCTir8T4RAjpXAKC8qRHIrQXxIA3O1RP3BnC40LcVqgCgy+eS
c+edNr0sMUM+tq0jmICq39Q=
=PnAk
-END PGP SIGNATURE-
Re: unsetting PerlTransHandler
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 14 August 2003 13:48, Frank Maas wrote: |Location ... | PerlSetVar SkipTransHandler 1 |/Location I don't want to make it configurable. Torsten -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/O54ywicyCTir8T4RAss0AJ4rNMkqyKC0Tlh8tPZF5XbGc4GSeQCgjwto CvsUie4PVYy1QQ/MfsywCtI= =npMM -END PGP SIGNATURE-
Re: unsetting PerlTransHandler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 14 August 2003 18:20, Geoffrey Young wrote:
Frank Maas wrote:
Ehm... considering both solutions worked and the quoted paragraph,
shouldn't we read it as 'the results of this sequence can be used during
the translation phase, but are thrown away after the translation has
completed'. This would mean that the results are not discarded prior to
translation, but after translation and that would also explain why the
two solutions work...
well, they can only be used during translation if the URI is unaltered.
for instance, given the example we've seen already
PerlTransHandler MyPackage::transhandler
Location ...
PerlHandler MyPackage::handler
/Location
checking get_handlers() in transhandler() only works because the initial
merge (which is thrown away) ends up being the same merge as after
translation. if any (other) trans handlers meddle with $r-uri (which is
perfectly valid) then the initial get_handlers() call will report settings
completely different than the end Location that is finally applied to the
URL.
well, if a transhandler alters the Uri than maybe MyPackage::handler will not
be called at all, yes. But from the point of view at start of the request it
would be called.
so, I guess Location-specific settings can be used during translation,
much in the same way that you can break encapsulation in Perl by simply
accessing the object via its underlying hash - the feature works
currently due to the way things are implemented, but using it is not
guaranteed to work in the future (apache 2.0?), and may have unintended
consequences in the present. in other words, it's a bad idea and people
who know better certainly don't rely on it.
I'm wondering then for what reason that initial merge is done at all if not to
be used during name translation?
well, a translation handler cannot be sure that the $r-dir_config it gets was
really caused by the $r-uri it sees. Further, other handlers in later phases
can get completely different settings.
I've searched the standard modules for /r-uri\s*=/ and found only one
occurence in mod_rewrite with the [PT] flag. I assume the right solution
would be to do another merge based on the new uri if someone alters the uri
during name translation and plans to return DECLINED.
And as for apache 2, there I have found these lines:
if ((access_status = ap_location_walk(r))) {
return access_status;
}
if ((access_status = ap_run_translate_name(r))) {
return decl_die(access_status, translate, r);
}
Torsten
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE/O+VtwicyCTir8T4RAiiEAJ4rtu6tMCVrkho5eP3L3+Yz8NGQ9QCguIUb
oxm9P4ttWWeO0g7/BRb4raQ=
=iiYV
-END PGP SIGNATURE-
Re: How to restart the root server from within modperl?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tuesday 12 August 2003 11:50, Dirk Lutzebaeck wrote:
Dennis Stout writes:
On a whim, I would try writing a second script to do the actual shutdown
and restart of Apache.
Then have your mod_perl program either run it in the background (with a
) or fork it into another process.
Did exactly that but is has the effect that when the parent (root)
apache is killed it kills all children including the script itself. So
the server wont start again.
I have done something like this several times. My code (it works since 1998 on
a highly used WEB Server with perl5.005_3) looks like that:
...
sub sysclose {
require 'syscall.ph';
syscall SYS_close, shift()+0;
}
sub RLIMIT_NOFILE {7;} # this is for LINUX
sub getrlimit {
require 'syscall.ph';
my $x=xx8; # result
syscall SYS_getrlimit, shift()+0, $x;
unpack ii, $x;
}
sub close_fd {
my @l=getrlimit( RLIMIT_NOFILE );
my $l;
for( $l=0; $l$l[0]; $l++ ) {
next if( $l==2 ); # close all file descriptors except of STDERR
sysclose $l;
}
}
sub disconnect_from_apache {
use POSIX qw/setsid/;
setsid;
close_fd;
}
...
my $child=fork;
unless( defined $child ) {
...
return OK;
}
if( $child ) {
my $child_status=0;
if( waitpid( $child, 0 )==$child ) {
$child_status=$?;
}
if( $child_status==0 ) {
...
return OK;
} else {
# The first fork succeeded but the second failed
...
return OK;
}
} else {
# Child process: fork again to detach from parent process
$child=fork;
CORE::exit( 0 ) if( $child ); # parent exits
unless( defined $child ) {
...
CORE::exit( 1 );
}
# Now we are the 2nd child process.
$self-disconnect_from_apache;
$self-doit( ... ); # == here comes the real code
CORE::exit( 0 );
}
...
$self-doit() is called in a separate process group and is not killed by a
signal sent to the apache process group. Further, all files save STDERR are
closed. This is needed since the code runs under mod_perl and the long
running child process inherits the open connection to the browser. If this
connection is not closed the browser shows an endless spinning globe or
something like that in the upper right corner.
Torsten
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE/OSIAwicyCTir8T4RAv3RAKCXdpbHLQepeOZFCyXt1KkMVGnwPgCeNu7X
hlC1NSEv0NsA7LlM7lol7wI=
=xId6
-END PGP SIGNATURE-
unsetting PerlTransHandler
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a VirtualHost ... PerlTransHandler Handler Location ... /Location /VirtualHost and want to unset the TransHandler inside the Location. How to do that? Thanks Torsten -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/O2FrwicyCTir8T4RAsXlAKCr0SfbKsG/9iNbv4pjxv1rOodV1wCggKOQ zQ/hRg4aSVwUDr3brnJY+I8= =oKyR -END PGP SIGNATURE-
mod_rewrite + PerlTransHandler
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I am trying to get a PerlTransHandler called *after* some mod_rewrite processing. I thought if I configure the rewrite rules *before* the PerlTransHandler: RewriteEngine On RewriteRule ... [PT] PerlTransHandler Apache::TestTrans::transhandler it would work that way. But it does not. Apache::TestTrans::transhandler is always called *before* mod_rewrite processing. Is there a way to determine the handler order? Thanks Torsten -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+Kt+/wicyCTir8T4RAqmNAJsGfm6CaPueSjCRAIA/BZ1BgWtxxACfWCLY GAo8nB1xxL1r+7blx7+qbi8= =473P -END PGP SIGNATURE-
