rewrite rules in sections
Hi. I found and old thread about having rewrite rules inside
Perl sections in httpd.conf. In these mails it looks like there
is not an easy way to do this.
Is that still true ?
I've tried different guesses unsuccessfully:
$RewriteRule="^/(img/.*) http://other.server/$1";
$RewriteRule{"^/(img/.*)" } ="http://other.server/$1";
push @RewriteRule("^/(img/.*) http://other.server/$1");
any hints ?
--
- frankie -
Postprocess subrequest content
Hi.
If I want to postprocess content from a subrequest before sending it to the
client, I can't
my $subr = $r->lookup_uri($uri);
$subr->header_in("Content-length" => "0");
$subr->run;
because this will send the content to the client. What can I do to get the
content myself?
Thanx,
Joachim
--
"... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden
koennen."- Bertolt Brecht - Leben des Galilei
Re: Apache::AuthCookieDBI forgets its config
"Rob Bloodgood" <[EMAIL PROTECTED]> writes:
> So I finally decided to plunge into AuthCookie*, and settled on
> AuthCookieDBI cuz it's pretty complete, and meets my environment, and I
> don't have to subclass it to even try it.
>
> DAMN what a *!
>
> Oh, mostly it's an EXCELLENT module.
>
> Mostly.
>
> For starters, as verbose as the docs are, they aren't as clear as one would
> hope. HOWEVER I finally got it to where everything LOOKS right, but I still
> have no go.
>
> As I delved into the problem, I found the following:
>
> The module has a BEGIN {} block that reads the server config for parameters
> of the form
> PerlSetVar MyRealmSecretKeyFile "/etc/httpd/conf/secretkeyfile.txt"
>
> into the module global hash %SECRET_KEYS
>
> and the docs recommend it be
> -rw--- root root
>
> so that it's only readable on server startup.
>
> HOWEVER, whenever the module is actually invoked, %SECRET_KEYS is empty!
>
I discovered the same thing. I think the problem is that the BEGIN
block as written, only considers parameters defined in the *main
server*. So if you have any PerlSetVar in a Virtual Server, it will
not be found.
A kludgy workaround is to move the PerlSetVar out of any Virtual
Server sections. A better option is to reimplement the mechanism for
populating the SECRET_KEYS hash, so that Virtual Servers are handled
properly.
--
Vegard Vesterheim : Phone: +47 73593002
Runit AS: Fax: +47 73591700
N-7465 Trondheim, NORWAY: Email: [EMAIL PROTECTED]
Re: Apachecon folks
At 09:30 PM 4/3/01 -0500, Dave Rolsky wrote: >Anyone here want to get together? I'm in room 945 and bored. I think >matt Sergeant is here too but I couldn't find him at the bar. Did you check under the bar...? I'm here... and I think Stas, Eric Cholet, and others were interested in doing dinner around 7 or 8. They'll probably check their mail soon? Up until an hour ago, I didn't realize how beat I'm still feeling from Jetlag (normally I'm 15 hours ahead of California time), so I'm turning in early... John Groenveld posted to the BOF schedule thread about wanting to go out though.. Maybe everyone who wants to should just go down to the bar and chill out as people gather? Later, Gunther
Apachecon folks
Anyone here want to get together? I'm in room 945 and bored. I think matt Sergeant is here too but I couldn't find him at the bar. -dave /*== www.urth.org We await the New Sun ==*/
Re: internal_redirect
Rob Bloodgood muttered: > OK 1: none of the example environments you listed that your programmers are > in include straight mod_perl... in fact they are all CGI emulation layers of > varying degrees of protection/dirtiness. Do I read you correctly? Yes, they're all CGI emulations. > Well, this is all fine except for one important detail: HOW, and I mean, if > you can't answer this you haven't solved the problem, but HOW do you know > that your programmers' programs are going to fire a 503 if there is a > database error > ... > But the only way for this setup to work is if the PROGRAMMERS know that if a > database call fails, to throw 503: > ... > Otherwise, all of this fancy footwork you're doing will be > pointless. You are correct, but I know, they'll fire a 503 because they all use a DB class we provide in our API to connect to the DB (no one connects 'directly' using DBI). Since we've overridden DBI's connect method with one of our own, we can fire a 503 when the DB connection fail. Thanks again, -Jim -- <[EMAIL PROTECTED]> (Replace Z's with E's to reply) "Camel's weren't designed to smell good. Neither was Perl." -Larry Wall PGP signature
RE: Apache::AuthCookieDBI forgets its config [UPDATE]
> HOWEVER, whenever the module is actually invoked, %SECRET_KEYS is empty!
>
> Here's the BEGIN{} block:
> BEGIN {
> my @keyfile_vars = grep {
> $_ =~ /DBI_SecretKeyFile$/
> } keys %{ Apache->server->dir_config() };
> foreach my $keyfile_var ( @keyfile_vars ) {
> my $keyfile = Apache->server->dir_config( $keyfile_var );
> my $auth_name = $keyfile_var;
> $auth_name =~ s/DBI_SecretKeyFile$//;
> unless ( open( KEY, "<$keyfile" ) ) {
> Apache::log_error( "Could not open keyfile for
> $auth_name in file
> $keyfile" );
> } else {
> $SECRET_KEYS{ $auth_name } = ;
> close KEY;
> }
> }
> }
OK, more examination reveals that:
At the time this BEGIN block is running, this call:
my @keyfile_vars = grep {
$_ =~ /DBI_SecretKeyFile$/
} keys %{ Apache->server->dir_config() };
is returning EMPTY.
Meaning it's evaling too early to see the dir_config??? Or what?
PerlModule Apache::AuthCookieDBI
PerlSetVar AdminPath /admin
PerlSetVar AdminLoginScript /scripts/adminlogin.pl
#PerlSetVar AdminLoginScript /error/adminlogin.html
# Optional, to share tickets between servers.
#PerlSetVar AdminDomain .domain.com
# These must be set
PerlSetVar AdminDBI_DSN "dbi:Oracle:STATS"
PerlSetVar AdminDBI_SecretKeyFile /etc/httpd/conf/admin.secret.key
# etc.
Ideas?
L8r,
Rob
#!/usr/bin/perl -w
use Disclaimer qw/:standard/;
RE: internal_redirect
> Rob, thanks for pointing me in the right direction. Your advise > helped me find a solution that works for my situation. You're welcome! > I'm working on an API that sits between an Oracle DB and bunch of web > application programmers. Unfortunately, the programmers run their > apps under a variety of perl-handlers (Apache::Registry, > Apache::RegistryNG, > Apache::RegistryFilter, etc). None of the programmers follow any > sort of standard method for handling exceptions, so I can't assume > that 'return OK;' will ever be called (in fact I'm pretty sure, it > will never be called). What I've been trying to do is kind of 'take > over' the request, whenever a programmer fails to connect to the DB and > redirect the browser to a handler that can put up a custom 503 page > for each application. OK 1: none of the example environments you listed that your programmers are in include straight mod_perl... in fact they are all CGI emulation layers of varying degrees of protection/dirtiness. Do I read you correctly? > I finally settled on putting the following in conf file for the web > sites: > > ErrorDocument 503 " content="0;URL=/DBConnectError.cgi"> > > >SetHandler perl-script >PerlHandler Tec::Api::DBConnectError > Well, this is all fine except for one important detail: HOW, and I mean, if you can't answer this you haven't solved the problem, but HOW do you know that your programmers' programs are going to fire a 503 if there is a database error > It seems to work for just about every perl handler the programmers are > using, as long as they doesn't use Carp::fatalsToBrowser, which > raises a whole new set of problems. (you could always chmod 000 `find /usr/lib/perl5 -name fatalsToBrowser.pm` :-) > If you see any issues with my solution, please chime in. Well as far as I can see, you're trying to ensure that the programmers are correctly connected to the database. It *looks* like /DBConnectError.cgi is a reconnect setup. Presumably, this has an API that your programmers are using to get DB handles (DBI?). But the only way for this setup to work is if the PROGRAMMERS know that if a database call fails, to throw 503: my $dbh = DBI->connect(Local::get_connect_args) or print "Status: 503\n\n", exit; Otherwise, all of this fancy footwork you're doing will be pointless. Is there something I'm missing?
Re: FW: Changes to BOF schedule..!
I just got into the Westin. If anyone else is around, I'd be into meeting for drinks or late dinner. John [EMAIL PROTECTED]
Re: internal_redirect
Rob, thanks for pointing me in the right direction. Your advise
helped me find a solution that works for my situation.
I'm working on an API that sits between an Oracle DB and bunch of web
application programmers. Unfortunately, the programmers run their
apps under a variety of perl-handlers (Apache::Registry, Apache::RegistryNG,
Apache::RegistryFilter, etc). None of the programmers follow any
sort of standard method for handling exceptions, so I can't assume
that 'return OK;' will ever be called (in fact I'm pretty sure, it
will never be called). What I've been trying to do is kind of 'take
over' the request, whenever a programmer fails to connect to the DB and
redirect the browser to a handler that can put up a custom 503 page
for each application.
I finally settled on putting the following in conf file for the web
sites:
ErrorDocument 503 "
SetHandler perl-script
PerlHandler Tec::Api::DBConnectError
It seems to work for just about every perl handler the programmers are
using, as long as they doesn't use Carp::fatalsToBrowser, which raises a whole
new set of problems.
If you see any issues with my solution, please chime in.
Thanks again for you help.
-Jim
Rob Bloodgood muttered:
> > I'm trying to handle an exception using an internal_redirect. I
> > can get it to work by redirecting to a static page, but when I try to
> > redirect to a modperl handler, I'm run into problems.
> >
> > Here are the two versions of code (BTW, the handler works fine when I
> > access it directly via the browser).
> >
> > ## ver. 1
> > print STDERR "$@";
> > require Apache;
> > my $r = Apache->request;
> > $r->internal_redirect("/DBConnectError.cgi");
> >
> > ## ver. 2
> > print STDERR "$@";
> > require Apache;
> > my $r = Apache->request;
> > $r->internal_redirect("/errordocs/503.html");
> >
> > When I run the modperl handler, the browser prompts me and asks if I
> > want to save the output of the cgi script that raised the error, but
> > it never displays the content from the handler. The static file
> > version works great and the browser displays it's content.
>
> Hmm... First of all, the Guide (and experience :-) sez that IMMEDIATELY
> after running
>
> $r->internal_redirect(blah);
>
> one should
>
> return OK;
>
> Secondly, I would suggest doing it differently:
> tell the request object that the handler returned code 503, and in
> httpd.conf:
>
> ErrorDocument 503 /DBConnectError.cgi
>
> I just wrote this handler in 2 minutes, that demonstrates:
>
> =
> package Stat::Testfail;
>
> use strict;
>
> sub handler {
> my $r = shift;
>
> $r->status(503);
> return 503;
> }
>
> 1;
> =
>
> with the following httpd.conf entry:
>
> SetHandler perl-script
> PerlHandler +Stat::Testfail
>
>
> and it works like I've described:
>
> # telnet localhost 80
> GET /testonly HTTP/1.0
>
> HTTP/1.1 503 Service Temporarily Unavailable
> Date: Tue, 03 Apr 2001 18:01:28 GMT
> Server: Apache/1.3.9 (Unix) (Red Hat/Linux) mod_perl/1.25
> Connection: close
> Content-Type: text/html
>
>
> An Error Occurred
>
> An Error Occurred
> 503 Service Temporarily Unavailable
>
>
>
> (Naturally this would have been different if i'd set an ErrorDocument 503).
>
> HTH!
>
> L8r,
> Rob
>
--
<[EMAIL PROTECTED]> (Replace Z's with E's to reply)
Okay, I got Linux installed. So where's the free beer.
-Anonymous
PGP signature
Apache::AuthCookieDBI forgets its config
So I finally decided to plunge into AuthCookie*, and settled on
AuthCookieDBI cuz it's pretty complete, and meets my environment, and I
don't have to subclass it to even try it.
DAMN what a *!
Oh, mostly it's an EXCELLENT module.
Mostly.
For starters, as verbose as the docs are, they aren't as clear as one would
hope. HOWEVER I finally got it to where everything LOOKS right, but I still
have no go.
As I delved into the problem, I found the following:
The module has a BEGIN {} block that reads the server config for parameters
of the form
PerlSetVar MyRealmSecretKeyFile "/etc/httpd/conf/secretkeyfile.txt"
into the module global hash %SECRET_KEYS
and the docs recommend it be
-rw--- root root
so that it's only readable on server startup.
HOWEVER, whenever the module is actually invoked, %SECRET_KEYS is empty!
Here's the BEGIN{} block:
BEGIN {
my @keyfile_vars = grep {
$_ =~ /DBI_SecretKeyFile$/
} keys %{ Apache->server->dir_config() };
foreach my $keyfile_var ( @keyfile_vars ) {
my $keyfile = Apache->server->dir_config( $keyfile_var );
my $auth_name = $keyfile_var;
$auth_name =~ s/DBI_SecretKeyFile$//;
unless ( open( KEY, "<$keyfile" ) ) {
Apache::log_error( "Could not open keyfile for $auth_name in file
$keyfile" );
} else {
$SECRET_KEYS{ $auth_name } = ;
close KEY;
}
}
}
My temporary solution was to patch the handlers to understand a new
PerlSetVar:
# Get the secret key.
my $secret_key = $SECRET_KEYS{ $auth_name };
unless ( defined $secret_key ) {
+ if (not defined ($SECRET_KEYS{ $auth_name } =
+ _dir_config_var($r, 'DBI_SecretKeyFile'))) {
$r->log_reason( "Apache::AuthCookieDBI: didn't the secret key from for
auth realm $auth_name", $r->uri );
return undef;
+ } else {
+ $secret_key = $SECRET_KEYS{ $auth_name };
}
}
But this seems crufty.
What I'd prefer to do is fix the init section so that it works. I can't
find anything in the mod_perl docs or the Guide that helps.
Suggestions??
TIA
L8r,
Rob
#!/usr/bin/perl -w
use Disclaimer qw/:standard/;
Apache::Filter doesn't filter right
I'm having a problem with Apache::Filter (and Apache::OutputChain) which I don't think is related to Apache::Filter itself, but I can't seem to track the problem down. I wrote a content handler which outputs XML, which I want to then be processed by AxKit. So, I did: SetHandler perl-script PerlSetVar Filter On PerlHandler HTTPFilter AxKit The output that I get is the combination of HTTPFilter's output, and AxKit's output (one right before the other). So, it seems that HTTPFilter's output is successfully making it into AxKit (otherwise it wouldn't process its output correctly), but is still making its way to the browser. Any ideas? --man Michael A. Nachbaur "Lead me not into temptation... I can find it myself."
ANNOUCE: HTML::Mason 1.015
The URL http://masonhq.com/download/HTML-Mason-1.015.tar.gz has entered CPAN as file: $CPAN/authors/id/J/JS/JSWARTZ/HTML-Mason-1.015.tar.gz size: 273604 bytes md5: a4e92af6963184b820dd39ddfdaafa8c Mason is a component-based web site development system with caching, debugging, and previewing facilities. Check out http://www.masonhq.com for more information. This release fixes a few incompatibility bugs with earlier versions of mod_perl (< 1.21_01) that were introduced in 1.01. Jon
RE: internal_redirect
> I'm trying to handle an exception using an internal_redirect. I
> can get it to work by redirecting to a static page, but when I try to
> redirect to a modperl handler, I'm run into problems.
>
> Here are the two versions of code (BTW, the handler works fine when I
> access it directly via the browser).
>
> ## ver. 1
> print STDERR "$@";
> require Apache;
> my $r = Apache->request;
> $r->internal_redirect("/DBConnectError.cgi");
>
> ## ver. 2
> print STDERR "$@";
> require Apache;
> my $r = Apache->request;
> $r->internal_redirect("/errordocs/503.html");
>
> When I run the modperl handler, the browser prompts me and asks if I
> want to save the output of the cgi script that raised the error, but
> it never displays the content from the handler. The static file
> version works great and the browser displays it's content.
Hmm... First of all, the Guide (and experience :-) sez that IMMEDIATELY
after running
$r->internal_redirect(blah);
one should
return OK;
Secondly, I would suggest doing it differently:
tell the request object that the handler returned code 503, and in
httpd.conf:
ErrorDocument 503 /DBConnectError.cgi
I just wrote this handler in 2 minutes, that demonstrates:
=
package Stat::Testfail;
use strict;
sub handler {
my $r = shift;
$r->status(503);
return 503;
}
1;
=
with the following httpd.conf entry:
SetHandler perl-script
PerlHandler +Stat::Testfail
and it works like I've described:
# telnet localhost 80
GET /testonly HTTP/1.0
HTTP/1.1 503 Service Temporarily Unavailable
Date: Tue, 03 Apr 2001 18:01:28 GMT
Server: Apache/1.3.9 (Unix) (Red Hat/Linux) mod_perl/1.25
Connection: close
Content-Type: text/html
An Error Occurred
An Error Occurred
503 Service Temporarily Unavailable
(Naturally this would have been different if i'd set an ErrorDocument 503).
HTH!
L8r,
Rob
Re: mirroring data across a server cluster
Paul Cotter wrote: > [OT] - but... I disagree somewhat about OT; I see your point but, I want to use this class specifically in mod_perl handlers. Also, clustered servers are definitely on topic, I think. > Do not throw out database replication as a solution. I remember a previous discussion way back on this list comparing performance differences between filesystem and database performance. I believe an eight-fold performance advantage for filesystems was found. While no benchmark applies directly to anything in the real world, I can use a clear performance advantage like this. > Even simplistic methods such as replacing all updates with stored > procedures that can update across multiple data-bases (eg Oracle Sybase etc) > will have problems. If you wish to separate the servers geographically then > loss of network will cause problems unless you adopt a store-and-forward > basis. I'm not considering geographical separation, fortunately. But couldn't that be handled by copying the total contents of the data store from a peer, assuming a small (< 2MB) data store and a fast (100 Mbps) network, plus queuing incoming updates while the copy is in process? > One method that has a reasonable level of success is a transaction log > analyser. Updates (as opposed to reads) are applied to a single server and > the transaction log analyser applies them to the other servers. However, for > ease of creation and maintenance a publish-and-subscribe replication system > is easiest. Remember that only certain data need be replicated. I have tried > in the past to extract to cached flat files for performance. At the end of > the day it is usually cheaper to go out and buy more hardware. I'm working in an environment with a very high write to read (.7 to 1) ratio. I like MySQL database replication, and it will remain part of this project. I just think it makes better sense to use something else with the 2 small data stores I'm dealing with, which have a few thousand records each, and get updated many times a second during peak traffic. --Christopher
Re: Long waits on SQL Stored Procs. Should I use chained contenthandlers?
At 7:49 AM -0700 4/3/01, Wim Kerkhoff wrote: >Robert Landrum wrote: >> >> At 2:06 PM + 4/2/01, [EMAIL PROTECTED] wrote: > >> >Any ideas? I cant, for the life of me, figure out how this would work with >> >http redirects, and thought there might be something with >>mod_perl that would >> >help this. Fork() maybe. I'm trying a few ideas. >> >> It's probably out of date, but the CGI::Push module does exactly >>what you want. >> >> The doc isn't real clear, but I've used this once to do exactly what >> you're doing. Unfortunatly, I can no longer find the code I wrote... >> >> Basically, CGI::Push sends a multipart mime message to the browser. >> The first part of that is an HTML document, which the browser renders >> immediatly. The second part is the confirmation HTML, which the >> browser also renders in place of the original document. > >Does this work with non-Netscape browsers, such as IE? I was going to >suggest this multipart MIME trick, but I thought I read in the CGI.pm >book that server push only worked with Netscape browsers. Actually, It doesn't work at all anymore. I just tested it with Netscape and IE. Bummer. I wrote the code back in 1998 or 1999... I guess that would have been Netscape 3.0 and IE 4. Browser technology peaked with lynx. At least you can expect the same results with just about every version ever written. Rob -- As soon as you make something foolproof, someone will create a better fool.
Re: Long waits on SQL Stored Procs. Should I use chained contenthandlers?
Robert Landrum wrote: > > At 2:06 PM + 4/2/01, [EMAIL PROTECTED] wrote: > >Any ideas? I cant, for the life of me, figure out how this would work with > >http redirects, and thought there might be something with mod_perl that would > >help this. Fork() maybe. I'm trying a few ideas. > > It's probably out of date, but the CGI::Push module does exactly what you want. > > The doc isn't real clear, but I've used this once to do exactly what > you're doing. Unfortunatly, I can no longer find the code I wrote... > > Basically, CGI::Push sends a multipart mime message to the browser. > The first part of that is an HTML document, which the browser renders > immediatly. The second part is the confirmation HTML, which the > browser also renders in place of the original document. Does this work with non-Netscape browsers, such as IE? I was going to suggest this multipart MIME trick, but I thought I read in the CGI.pm book that server push only worked with Netscape browsers. -- Regards, Wim Kerkhoff
Re: Long waits on SQL Stored Procs. Should I use chained contenthandlers?
At 2:06 PM + 4/2/01, [EMAIL PROTECTED] wrote:
>I need to run some stored procedures that take upwards of a minute to generate
>result sets. Ok, thats grand but I dont want the browser to sit there and
>twiddle.
>
>I'd like to display an animated gif. Simple. Right? I hope.
>
>I'm looking into chained handlers in my mod_perl code, but I'm not
>sure if this
>is what I need.
>
>0) Request page and report.
>1) Push 'Waiting...' animated gif
>2) Process report, Perl waits for result set
>3) Perl pushes the report html to the browser as if it opened in a target =
>_blank window. IE: That same window...
>Stumped (or rather -> RTFMing),
>
>Any ideas? I cant, for the life of me, figure out how this would work with
>http redirects, and thought there might be something with mod_perl that would
>help this. Fork() maybe. I'm trying a few ideas.
It's probably out of date, but the CGI::Push module does exactly what you want.
The doc isn't real clear, but I've used this once to do exactly what
you're doing. Unfortunatly, I can no longer find the code I wrote...
Basically, CGI::Push sends a multipart mime message to the browser.
The first part of that is an HTML document, which the browser renders
immediatly. The second part is the confirmation HTML, which the
browser also renders in place of the original document.
The basic syntax is
use CGI::Push qw/:standard/;
do_push(-next_page => \&header);
sleep 30;
do_push(-next_page => \&body);
do_page(-next_page => sub { return undef; });
&header and &body both return a FULL html document, including the
headers. Returning undef terminates the connection with the browser.
Good luck,
Rob
--
As soon as you make something foolproof, someone will create a better fool.
FW: Changes to BOF schedule..!
FYI...
> -Original Message-
> From: Rodent of Unusual Size [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 02, 2001 6:59 PM
> To: BOF submitters
> Subject: Re: Changes to BOF schedule..!
>
>
> Rodent of Unusual Size wrote:
> >
> > Due to a bit of confusion, the BOF schedule next week requires
> > some serious revamping. The space we were going to use on
> > Wednesday will not be available until Thursday, and some of the
> > BOFs on Thursday and Friday need to be moved around to avoid
> > space collisions as well.
>
> {sigh} More confusion, fortunately undoing some of the earlier
> concerns. We *do* have a BOF room for Wednesday, and we
> *do* have at least one BOF room (and sometimes two) on Thursday
> and Friday.
>
> More info as it comes available..
> --
> #kenP-)}
>
> Ken Coar
