Re: OSCON ideas
Quoting Perrin Harkins ([EMAIL PROTECTED]): > As many of you probably know, the call for participation in this year's > Open Source Conference has gone out > (http://conferences.oreillynet.com/cs/os2003/create/e_sess). I'm > thinking about possible talks to submit and I want a little feedback on > what people are most interested in. Here are two options I'mconsidering: > > 1) Database Objects in Perl > > This talk would focus on the database mapping options for Perl, > including modules like Tangram, Class::DBI, SPOPS, etc. It would > examine the differences in features, ease of use, and performance and > include a set of hand-coded classes using straight DBI for comparison. This would be a very interesting talk to attend. Alot of applications hook in to databases, so the interest coverage should be pretty high. I've looked at a few of these, and where I struggle is trying to find what is the "right tool for the job". When is Tangram too much of a tool and when is straight DBI not enough? What approaches scales as your needs change. I'd throw Alzabo in there as well. Something about the Object to Relational mapping is worthy of inclusion. IIRC, there's also a brief discussion of this in the Advanced Perl Programming book. Maybe I just can't get my brain around some of these frameworks, but I haven't found one that "feels right" when I have to do a query that isn't just a simple select or join of two tables. > > 2) The Perl Pet Store > > This would be a discussion of porting the J2EE Pet Store reference > application to Perl. It would cover Perl equivalents for various J2EE > features, and talk about what was easier or harder to do in Perl. > Because of the size of the Pet Store codebase and the complexity of the > environment required to run it (multiple databases, etc.), it may not be > possible to do a good performance benchmark. However comparisons on > other fronts (amount of code, ease of maintenance, etc.) would be made. I like this one too. > > What do you guys think? > > - Perrin
Re: question about using a proxy with mod_perl
I believe that the Rewrite rule matches only the document root portion
of the URL.
So for a request
http://a.blah.com/mypath/mypage.html
All you will get to match on is this much
/mypath/mypage.html
To do what you are trying to do, I believe you'll need to use some RewriteCond
directives, something like (read: I'm just doing this from memory, you'll
need to test)...
RewriteCond %{HTTP_HOST} ^b
RewriteRule ^/(.*) http://b.blah.com:4374/$1 [P,L]
Hope that helps or points you in the right direction.
Quoting Brian Hirt ([EMAIL PROTECTED]):
>
> I have a question about setting up a proxy for a mod_perl server. I've
> got a simple proxy set up that listens on port 80 and proxies to the
> mod_perl server running on a different port.
>
> For example. http://blah.blah.com/anything/ will go to
> http://blah.blah.com:4374/anything/ and the rules to do that are below.
>
> RewriteEngine on
> RewriteLogLevel 0
> RewriteRule ^/(.*)$ http://blah.blah.com:4374/$1 [P,L]
> NoCache *
> ProxyPassReverse / http://blah.blah.com/
>
> This is fine when you are proxying a single machine name, but how would
> i set up a proxy that would send http://a.blah.com ->
> http://a.blah.com:4374, http://b.blah.com -> http://b.blah.com:4374,
> etc etc etc. There are about 40 different names that need to be
> proxied, and it's important that the destination name is the same as the
> source machine name.
>
> It seems like something like
> RewriteRule ^http://([^.]+).blah.com/(.*)$ http://$1.blah.com:4374/$2
> [P,L]
>
> should work, but it doesn't.
>
> --
> Brian Hirt <[EMAIL PROTECTED]>
Re: apache2, DBD/Oracle problem
I does seem to be an ORACLE environment issue.
IIRC, the original post had the Oracle environment variables set in a
BEGIN block.
I ran into a similar issue, where I changed ORACLE_HOME and TNS_ADMIN to
point to a new location. I set these in a BEGIN block in my startup.pl
file. But the mod_perl code kept going back to the old location.
I finally tracked it down that another section of my code base was setting
the Oracle environment variables back to their original locations. Once
I tracked that down and corrected it, I had no more problems. But for
awhile I thought either mod_perl was loosing it.
So"it could be" that another script (ie. something loaded in the
startup.pl or equivalent) is affecting the Oracle environment variables
in some way. That would be consistent with your observations that the
script works fine on the command-line, but not in the mod_perl environment.
You might want to print out the Oracle environment variables right before
you do your connect, just to test this.
Hopefully it's that simple.
Quoting Atsushi Fujita ([EMAIL PROTECTED]):
> Hi Fredo,
>
> I had a similar problem in similar environment.
> My simple DBD program worked fine on normal shell and normal apache, but it
> didn't work under the mod_perl2.
> It showed error as following in apache error_log.
>
> [error_log]
> DBI->connect(ynt0) failed: (UNKNOWN OCI STATUS 1804) OCIInitialize. Check
> ORACLE_HOME and NLS settings etc. at
> /yopt/httpd-2.0.39_prefork_perl5.6.1normal/cgi-bin/test1.cgi line 42
> [Mon Jul 29 20:15:37 2002] [error] 25703: ModPerl::Registry: `Cannot connect:
> (UNKNOWN OCI STATUS 1804) OCIInitialize. Check ORACLE_HOME and
> NLS settings etc.at
> /yopt/httpd-2.0.39_prefork_perl5.6.1normal/cgi-bin/test1.cgi line 42.
>
>
> This looks like a problem of %ENV.
> So, I inserted debug code in DBD.pm to output %ENV, and it was correct in
> DBD.pm under mod_perl2.
> But I didn't check deep C code, I gave up to check it...
>
> My machine is as following.
> - perl5.6.1(non thread)
> - DBI-1.30
> - DBD-Oracle-1.12
> - mod_perl1.99_04(DSO build)
> - apache2.0.39(prefork)
> - Oracle9.0.1.3 for Linux in same machine
>
> And I attached my last mail.
> Sorry for being long mail...
>
> Thank you.
>
> Atsushi
>
>
> - Original Message -
> From: "Atsushi Fujita" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, July 29, 2002 8:39 PM
> Subject: mod_perl2 & DBD::Oracle problem
>
>
> > Hi all,
> >
> > I am trying to use DBD::Oracle1.12 on mod_perl2.
> > But it doesn't work fine.
> > It shows error as following in error_log at $dbh = DBI->connect.
> >
> > [error_log]
> > DBI->connect(ynt0) failed: (UNKNOWN OCI STATUS 1804) OCIInitialize. Check
> > ORACLE_HOME and NLS settings etc. at
> > /yopt/httpd-2.0.39_prefork_perl5.6.1normal/cgi-bin/test1.cgi line 42
> > [Mon Jul 29 20:15:37 2002] [error] 25703: ModPerl::Registry: `Cannot
> connect:
> > (UNKNOWN OCI STATUS 1804) OCIInitialize. Check ORACLE_HOME and
> > NLS settings etc.at
> > /yopt/httpd-2.0.39_prefork_perl5.6.1normal/cgi-bin/test1.cgi line 42.
> >
> >
> >
> > [test1.cgi]
> > use DBI;
> >
> > my $dsn = 'dbi:Oracle:';
> > my $user = 'username/password';
> > my $password = '';
> >
> > $ENV{'ORACLE_HOME'} = '/u01/app/oracle/product/9.0.1';
> > $ENV{'ORACLE_SID'} = 'ynt0';
> > $ENV{'NLS_LANG'}= 'japanese_japan.ja16euc';
> >
> > print "ORACLE_HOME=$ENV{'ORACLE_HOME'}\n";
> > print "ORACLE_SID=$ENV{'ORACLE_SID'}\n";
> > print "NLS_LANG=$ENV{'NLS_LANG'}\n";
> > print "DSN=$dsn$ENV{'ORACLE_SID'}\n";
> >
> > $dbh = DBI->connect("$dsn$ENV{'ORACLE_SID'}", $user, $password)
> > or die "Cannot connect: ".$DBI::errstr;
> > ...
> >
> >
> > At first, I suspect that the reason is %ENV in this script.
> > But I set surely, and this output as following.
> >
> > [Broser output HTML]
> > ORACLE_HOME=/u01/app/oracle/product/9.0.1
> > ORACLE_SID=ynt0
> > NLS_LANG=japanese_japan.ja16euc
> > DSN=dbi:Oracle:ynt0
> >
> > Internal Server Error
> > The server encountered an internal error or misconfiguration and was unable
> to
> > complete your request.
> >
> >
> >
> > And if I turned off the mod_perl, it works fine on normal CGI-script.
> > This error occurred only mod_perl.
> > (I tested mod_perl1.26 & apache 1.3.26, it worked fine...)
> >
> > My machine is as following.
> > - perl5.6.1(non thread)
> > - DBI-1.30
> > - DBD-Oracle-1.12
> > - mod_perl1.99_04(DSO build)
> > - apache2.0.39(prefork)
> >
> >
> > [httpd.conf](is this wrong??)
> > LoadModule perl_module modules/mod_perl.so
> > ...
> >
> > PerlModule ModPerl::Registry
> >
> > SetHandler perl-script
> > PerlResponseHandler ModPerl::Registry
> > PerlOptions +ParseHeaders
> > Options +ExecCGI
> >
> >
> >
> >
> >
> > Thanks,
> >
> > Atsushi.
>
>
>
> - Original Message -
> From: "Fredo Sartori" <[EMAIL PROTECT
Re: PerlTransHanlder and path_info() question
Does your handler use Apache::Registry or Apache::PerlRun by any chance?
I did find this code snippet from the ap_add_cgi_vars() within,
the Apache core...
if (r->path_info && r->path_info[0]) {
/*
* To get PATH_TRANSLATED, treat PATH_INFO as a URI path.
* Need to re-escape it for this, since the entire URI was
* un-escaped before we determined where the PATH_INFO began.
*/
request_rec *pa_req;
pa_req = ap_sub_req_lookup_uri(ap_escape_uri(r->pool, r->path_info), r);
>From this it seems that, if Apache is asked to setup a CGI environment,
and if path_info is defined, then it will invoke a sub_request.
Quoting giorgos zervas ([EMAIL PROTECTED]):
> Hi,
>
> I followed Lyle's advice and moved my module down to the
> PerlFixupHandler phase and also added the extra logging info.
>
> However I still get, as predicted, one initial request for the correct
> URI and another subrequest for a URI which corresponds to the value I
> set the path_info to. If I don't set the path_info the subrequest
> disappears. So I still wonder why setting the path_info causes a
> subrequest to happen?
>
> Any ideas?
>
> Many thanks,
> Giorgos
>
> Lyle Brooks wrote:
> > Quoting Randy Harmon ([EMAIL PROTECTED]):
> >
> >>I have a similar problem. Yes, I'm getting a subrequest happening. Any
> >>suggestions as to why it's likely to be happening? I'm not explicitly
> >>requesting it.
> >>
> >>In my case, if the requested file is in a directory that didn't exist, this
> >>situation occurs even if I simply return DECLINED; I'd guess the default
> >>handlers are setting path_info, which for some reason is resulting in this
> >>subrequest..
> >>
> >>RAndy
> >
> >
> > This is just a general guess, as depending on your configuration alot of
> > factors (read: modules) could be at work.
> >
> > If I were going to debug it (giorgos's example) further, I'd probably try
> > to do the same operation as a FixupHandler, as opposed to a TransHandler.
> >
> > I say, that because the example was altering only the content generation
> > phase (ie. PerlHander). If moving the code down the request cycle caused
> > the subrequests went away, then you could narrow down what was generating
> > the requestsdown to those modules registered for earlier phases.
> >
> > I also used the term subrequest somewhat "generally", it could be from a
> > a subrequest or an internal redirect. You could insert some code in your
> > handler to clarify it, like this :
> >
> >my $r = shift;
> >
> >my $log = $r->server->log;
> >
> >$r->log->info("\n\nIncoming request");
> >$log->debug("uri = " . $r->uri);
> >
> >$log->debug("initial request - true") if $r->is_initial_req;
> >
> >$log->debug("internal redirect - true")
> > if ($r->is_main and ! $r->is_initial_req);
> >
> >$log->debug("subrequest - true") unless $r->is_main;
> >
> > Then set your LogLevel to "debug" in the httpd.conf file and watch your
> > error_log.
> >
> > HTH
> >
> > Lyle
>
>
>
Re: PerlTransHandler problem
Quoting Lyle Brooks ([EMAIL PROTECTED]): > Sounds like it's more of a DNS issue than a modperl issue. > > Depending on what your motivation for requiring the full name, you > may also explicitly set > > ServerName myserver.rhythm.com > UseCanonicalName off errr... should be UseCanonicalName On > > Quoting Rasoul Hajikhani ([EMAIL PROTECTED]): > > I am realy trying to make sure that all requests for > > http://myserver/ > > are treated as > > http://myserver.rhythm.com/ > > so that my other applications that depend on reading cookies down the > > request chain could actually do so... > > -r > > > > "Randal L. Schwartz" wrote: > > > > > > >>>>> "Rasoul" == Rasoul Hajikhani <[EMAIL PROTECTED]> writes: > > > > > > Rasoul> I am trying to implement a simple PerlTransHandler to change: > > > > > > Rasoul> http://myserver/ > > > > > > Rasoul> to > > > > > > Rasoul> http://myserver.rhythm.com/ > > > > > > Both of those are "/" as far as as $r->uri is concerned. > > > > > > What are you *really* trying to do? > > > > > > -- > > > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > > > <[EMAIL PROTECTED]> 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: PerlTransHandler problem
Sounds like it's more of a DNS issue than a modperl issue. Depending on what your motivation for requiring the full name, you may also explicitly set ServerName myserver.rhythm.com UseCanonicalName off Quoting Rasoul Hajikhani ([EMAIL PROTECTED]): > I am realy trying to make sure that all requests for > http://myserver/ > are treated as > http://myserver.rhythm.com/ > so that my other applications that depend on reading cookies down the > request chain could actually do so... > -r > > "Randal L. Schwartz" wrote: > > > > > "Rasoul" == Rasoul Hajikhani <[EMAIL PROTECTED]> writes: > > > > Rasoul> I am trying to implement a simple PerlTransHandler to change: > > > > Rasoul> http://myserver/ > > > > Rasoul> to > > > > Rasoul> http://myserver.rhythm.com/ > > > > Both of those are "/" as far as as $r->uri is concerned. > > > > What are you *really* trying to do? > > > > -- > > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > > <[EMAIL PROTECTED]> 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: PerlTransHandler problem
You are only going to have Transhandlers defined in the main server or
virtual host, not in any or containers.
Check and see if you have any other Transhandlers defined earlier in
your httpd.conf file. If an earlier Transhandler returns OK, then
later ones won't be called.
Quoting Rasoul Hajikhani ([EMAIL PROTECTED]):
> A funny thing is happening with my PerlTransHandler...
> It is not being called at all... :(
> I have added warn messages but they never appear in the error log.
> I am at a loss and hoping that some one may have an answer...
> -r
>
> Lyle Brooks wrote:
> >
> > Quoting Rasoul Hajikhani ([EMAIL PROTECTED]):
> > > Hello folks,
> > > I am trying to implement a simple PerlTransHandler to change:
> > >
> > > http://myserver/
> > >
> > > to
> > >
> > > http://myserver.rhythm.com/
> > >
> > > And here is my code:
> > >
> > > package MIS::GENERAL::FixURL;
> > >
> > > use Apache::Constants qw(DECLINED);
> > >
> > > use strict;
> > >
> > > sub handler
> > > {
> > > my $r = shift;
> > > my $uri = $r->uri;
> > >
> > > return DECLINED if ($uri =~ m/^.+\.rhythm\.com$/)
> >
> > IIRC, the $r->uri method is normally not going yield the hostname or
> > scheme (unless this is a proxy request).
> >
> > So for a request to http://www.rhythm.com/test/myfile.html
> >
> > $r->uri is going to return only
> >
> > /test/myfile.html
> >
> > You may want to do some logging to verify.
> >
> > Add
> >
> > use Apache::Log ();
> >
> > then inside your handler...
> >
> > my $log = $r->server->log;
> >
> > $log->debug("Processing request " . $r->uri);
> >
> > Hope that helps.
> >
> > >
> > > $uri=~ s/^(.+)/$1\.rhythm\.com/;
> > > $r->uri($uri);
> > >
> > > return DECLINED;
> > > }
> > >
> > > 1;
> > >
> > > Here is my https.conf entry:
> > > PerlTransHandler MIS::GENERAL::FixURL
> > >
> > > And here is my error when I type: s7.rhythm.com
> > >
> > > Invalid URI in request GET / HTTP/1.0
> > >
> > > But I get no error with: http://s7/
> > >
> > > Can some one tell me what am I doing wrong?
> > >
> > > Thanks in advance
> > > -r
Re: PerlTransHandler problem
Quoting Rasoul Hajikhani ([EMAIL PROTECTED]):
> Hello folks,
> I am trying to implement a simple PerlTransHandler to change:
>
> http://myserver/
>
> to
>
> http://myserver.rhythm.com/
>
> And here is my code:
>
> package MIS::GENERAL::FixURL;
>
> use Apache::Constants qw(DECLINED);
>
> use strict;
>
> sub handler
> {
> my $r = shift;
> my $uri = $r->uri;
>
> return DECLINED if ($uri =~ m/^.+\.rhythm\.com$/)
IIRC, the $r->uri method is normally not going yield the hostname or
scheme (unless this is a proxy request).
So for a request to http://www.rhythm.com/test/myfile.html
$r->uri is going to return only
/test/myfile.html
You may want to do some logging to verify.
Add
use Apache::Log ();
then inside your handler...
my $log = $r->server->log;
$log->debug("Processing request " . $r->uri);
Hope that helps.
>
> $uri=~ s/^(.+)/$1\.rhythm\.com/;
> $r->uri($uri);
>
> return DECLINED;
> }
>
> 1;
>
> Here is my https.conf entry:
> PerlTransHandler MIS::GENERAL::FixURL
>
> And here is my error when I type: s7.rhythm.com
>
> Invalid URI in request GET / HTTP/1.0
>
> But I get no error with: http://s7/
>
> Can some one tell me what am I doing wrong?
>
> Thanks in advance
> -r
Re: [OT] MVC soup (was: separating C from V in MVC)
Quoting Bill Moseley ([EMAIL PROTECTED]): > I, like many, find these discussion really interesting. I always wish > there was some write up for the mod_perl site when all was said and done. > But I guess one of the reasons it's so interesting is that there's more > than one correct point of view. I also find this thread extremely interesting. I didn't really know what MVC coding was before reading this thread, or that by trial and error what I had coded had gradually evolved to be more "MVC-like", but I'm really glad this thread came up. To me, the eagle book, "the guide", and the cookbook all help produce great tactical coding techniques, but this discussion helps fill in a framework for what I've found somewhat missing to date, and that is the employing of "strategic" coding techniques. I wish I had more to offer to the discussion, but I echo Bill's sentiments that a write-up would be much appreciated and I hope the the "OT" won't take the discussion off list, because I think it's has a great bearing on developing quality mod_perl enabled applications.
PATH-like module?
Is there a module that provides a PATH-like capability for URLs? The behavior I was looking for would do something like this... I request a URL /images/background.gif and then the web server (via this module or some other method) would look for the background.gif file in a series of directories similar to what the shell does to search your PATH for an executable. So, if URLPATH was set to /opt/local/images:/net/images, then we'd look for background.gif in each directory in turn. If not found in any of them, only then would a 404 returned. o Does such a module exist? o Is this available via some core directive? o Is there a better way to do the same thing? or is it just late at night and I'm missing something obvious. Thanks
Re: image corruption
Ok, a couple of things...
1) You want to move the $r->send_http_header; call up before calling
$template->process();
2) Modify $template->process( $file, $vars, $r) to
$template->process( $file, $vars) since you specify OUTPUT => $r
when you create the Template object (so it's re-dundant).
3) get rid of the $r->print( $output ) line as well, $template->process()
is going to send the output to Apache the way you have it setup.
4) As David Ranney pointed out in a previous post, you might want to
put your images somewhere else, or adjust your URL
You get a path_info part only for the virtual component of your URL
(ie. there's no filesystem component beyond /tt ), but your URL for
images/hello.gif is relative to /tt, which means your handler for
has got to fix things up.
...or..
If you make the URL hello.gif to resolve to something outside /tt,
then Apache should serve it up as a regular file, which I suspect is
what you want.
HTH
Lyle
Quoting Tim Noll ([EMAIL PROTECTED]):
> Whoops, I hacked up my example a little to make it easier it to read,
> and I accidentally removed the line:
> $file =~ s{^/}{};
> But, it was in the original. Really. :-)
>
> -Tim
>
>
> - Original Message -
> From: "Lyle Brooks" <[EMAIL PROTECTED]>
> To: "Tim Noll" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Tuesday, February 05, 2002 4:42 PM
> Subject: Re: image corruption
>
>
> > When I try this example, I find that this line
> >
> > > my $file = $r->path_info;
> >
> > will set $file to "/index.html" when I request the URL /tt/index.html
> >
> > which leads to an error message that says,
> >
> > reason: file error - /index.html: absolute paths are not allowed (set
> ABSOLUTE option)
> >
> > You may want to clip off the leading slash or set the Template Toolkit
> > option ABSOLUTE, depending on which suits your needs.
> >
> > Quoting Tim Noll ([EMAIL PROTECTED]):
> > > I'm attempting to use mod_perl and Template Toolkit to serve up
> > > templates. However, I'm having a problem with the images in those
> > > templates: They're passing through the content handler, and thus
> getting
> > > corrupted.
> > >
> > > My first thought was to return DECLINED from the content handler if
> the
> > > request is not for text/html content; however, since I'm using a
> > > Location directive, the content_type is always empty since there's
> no
> > > direct mapping to an actual image file. I could use an Alias to map
> the
> > > URI to the file, but then I wouldn't have the path_info that I'm
> using
> > > to call the template.
> > >
> > > Since my test code, using path_info, is based on an example from the
> > > Template Toolkit docs, I feel like I'm probably overlooking
> something
> > > basic. So, I'd appreciate it if someone could show me the error of
> my
> > > ways. :-)
> > >
> > > Here are the relevant chunks of config and code:
> > >
> > > from httpd.conf
> > > ---
> > > ...
> > >
> > > SetHandler perl-script
> > > PerlHandler Apache::Test::Mod
> > > PerlSetVar WEBROOT /usr/local/apache/tt/html
> > >
> > > ...
> > >
> > > Apache::Test::Mod
> > > -
> > > ...
> > > sub handler {
> > > my $r = shift;
> > >
> > > # this doesn't work
> > > #return DECLINED unless $r->content_type eq 'text/html';
> > >
> > > my $WEBROOT = $r->dir_config('WEBROOT')
> > > or return fail( $r, SERVER_ERROR, "'WEBROOT' not specified" );
> > >
> > > my $file = $r->path_info;
> > >
> > > my $vars = {
> > > content => $r->content_type,
> > > };
> > >
> > > $r->content_type('text/html');
> > > $r->no_cache(1);
> > >
> > > my $template = Template->new( {
> > > INCLUDE_PATH => "$WEBROOT:$WEBROOT/include",
> > > OUTPUT => $r,
> > > } );
> > > $template->process( $file, $vars, $r)
> > > or return fail( $r, SERVER_ERROR, $template->error );
> > >
> > > $r->send_http_header();
> > > $r->print( $output );
> > >
> > > return OK;
> > > }
> > > ...
> > >
> > > index.html (test template)
> > > --
> > >
> > >
> > > test
> > >
> > >
> > > content_type: [% content %]
> > > image:
> > >
> > >
> > >
> > >
> > > Thanks.
> > >
> > > -Tim
> > >
> > >
> >
>
Re: image corruption
When I try this example, I find that this line
> my $file = $r->path_info;
will set $file to "/index.html" when I request the URL /tt/index.html
which leads to an error message that says,
reason: file error - /index.html: absolute paths are not allowed (set ABSOLUTE option)
You may want to clip off the leading slash or set the Template Toolkit
option ABSOLUTE, depending on which suits your needs.
Quoting Tim Noll ([EMAIL PROTECTED]):
> I'm attempting to use mod_perl and Template Toolkit to serve up
> templates. However, I'm having a problem with the images in those
> templates: They're passing through the content handler, and thus getting
> corrupted.
>
> My first thought was to return DECLINED from the content handler if the
> request is not for text/html content; however, since I'm using a
> Location directive, the content_type is always empty since there's no
> direct mapping to an actual image file. I could use an Alias to map the
> URI to the file, but then I wouldn't have the path_info that I'm using
> to call the template.
>
> Since my test code, using path_info, is based on an example from the
> Template Toolkit docs, I feel like I'm probably overlooking something
> basic. So, I'd appreciate it if someone could show me the error of my
> ways. :-)
>
> Here are the relevant chunks of config and code:
>
> from httpd.conf
> ---
> ...
>
> SetHandler perl-script
> PerlHandler Apache::Test::Mod
> PerlSetVar WEBROOT /usr/local/apache/tt/html
>
> ...
>
> Apache::Test::Mod
> -
> ...
> sub handler {
> my $r = shift;
>
> # this doesn't work
> #return DECLINED unless $r->content_type eq 'text/html';
>
> my $WEBROOT = $r->dir_config('WEBROOT')
> or return fail( $r, SERVER_ERROR, "'WEBROOT' not specified" );
>
> my $file = $r->path_info;
>
> my $vars = {
> content => $r->content_type,
> };
>
> $r->content_type('text/html');
> $r->no_cache(1);
>
> my $template = Template->new( {
> INCLUDE_PATH => "$WEBROOT:$WEBROOT/include",
> OUTPUT => $r,
> } );
> $template->process( $file, $vars, $r)
> or return fail( $r, SERVER_ERROR, $template->error );
>
> $r->send_http_header();
> $r->print( $output );
>
> return OK;
> }
> ...
>
> index.html (test template)
> --
>
>
> test
>
>
> content_type: [% content %]
> image:
>
>
>
>
> Thanks.
>
> -Tim
>
>
Re: mod_perl make test fails
I experienced a similar problem (I was upgrading one thing, which let to upgrading another,... which led to why not upgrade just about everything :-) My configuration/versions are pretty similar. I modified lib/Apache/test.pm, at line 8 I put use URI::URL (); and then I modified t/internal/hooks.t, also at line 8 I added use URI::URL (); That seemed to get past the error and the tests passed. HTH > Hi there! > > I'm trying to compile apache_1.3.22+mod_perl-1.26 on a redhat 7.1 > linux box. I replace the original gcc 2.xx with gcc version 3.0.2 > and perl 5.6.0 with perl 5.6.1 both compiled in the same box. > > Any help will be highly appreciated > > _ Jose Albert > > These are the last lines of the output of 'make test' > > ../apache_1.3.22/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t > & > httpd listening on port 8529 > will write error_log to: t/logs/error_log > letting apache warm up...\c > done > /usr/bin/perl t/TEST 0 > Can't locate object method "new" via package "URI::URL" (perhaps > you forgot to load "URI::URL"?) at ../blib/lib/Apache/test.pm line > 252. > make: *** [run_tests] Error 255 > > * This is the error log ** > [root@lancelot mod_perl-1.26]# cat t/logs/error_log > [notice] Destruction->DESTROY called for $global_object > [Wed Nov 14 12:41:28 2001] [warn] [notice] child_init for process > 4115, report any problems to [no address given] >
RE: [OT] New Micro$oft vulnerability?
This helps alot. I've been looking for a concise map of the various phases and what returns codes take me where. I'll probably post it on my wall. > all phases up to and including content generation ought to behave exactly > the same... > > - DECLINED moves to the next handler in the phase > - DONE bypasses content generation, closes the connection, and goes directly > to the logging phase > - anything other than DONE, OK, or DECLINED terminates the phase and enters > the ErrorDocument cycle (where there may or may not be an actual > ErrorDocument configured) > A couple follow-up questions. What phases are run during the ErrorDocument cycle? One motivation I have is for these virus attacks, I'd like to send out a 403 - Forbidden right at the beginning (say, when someone asks for default.ida) and then I'd like to have the option of not logging it to keep it from growing my logs and distorting my log reports. Is there anyway to selectively tell a request not to even log this? Disable the log handler for the current request, maybe? > the only thing that varies across the phases is the meaning of OK > - for trans, auth, authz, and type checkers no further handlers are run > - for all others it is effectively the same as DECLINED > > HTH
Re: Querying Apache Configuration
Quoting Geoffrey Young ([EMAIL PROTECTED]): > > > > In the process, I been wondering is it possible to peek at the > > configuration directives/values of other modules (both Perl and C) > > via mod_perl? > > sort of - in both instances you have to do some tricks and break > encapsulation. for Perl you have to get the module's configuration using > Apache::ModuleConfig->get($r, package) where package- is the class of the > class in question. for C it's a bit trickier and may not work on all > platforms (it doesn't on windows) but you can check the archives for Doug's > example of getting mod_auth's AuthName directive if you really want to. > > basically, though, the data you are after is private and should only be > retrieved via the public interface. but this is Perl, so you are more asked > to play fair than you are required, and mod_auth doesn't have an > interface... I was looking over the mod_info source code, so I knew it could be done. I just didn't know if mod_perl provided an interface. And rather than request a URL which invoked mod_info, getting back the HTML, parsing through ityou get the idea, and so on and so forth, I thought that information "should" be available to a mod_perl handler via the mod_perl interface in a more or less object oriented manner. It's kinda like writing mod_info as a mod_perl handler, only allow the handler to get the data in an object oriented manner from the mod_perl interface.
Querying Apache Configuration
I've been studying Chapter 8 "Customizing the Apache Configuration
Process" in the Eagle book, and working through some test modules.
In the process, I been wondering is it possible to peek at the
configuration directives/values of other modules (both Perl and C)
via mod_perl?
Also, in my tests I tried the following code..
my $fname = $r->server->error_fname;
$log->debug("error log filename = $fname");
my $loglevel = $r->server->loglevel;
$log->debug("loglevel = = $loglevel");
and to my surprise they worked and came back with values. ($fname
with the value of my ErrorLog directive, and $loglevel with 7 which
corresponds to the debug level my LogLevel directive was set to.
error_fname() is not documented (at least my eyes didn't find it in
the Eagle book), but to my surprise it worked. I later found it
in the mod_perl sources.
loglevel() does not appear to be documented either, nor did I find a
sub for it in the mod_perl source. Why did that work? Is there
some AUTOLOADing going on here?
