You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Jon <jo...@3ev.com> on 2003/02/05 13:53:29 UTC
Re: Re-installing 1.99_08 binary or 1.99_05 RPM in Red Hat 8
[mp2]
(Just an informational post to round off the thread.)
The following worked for me, I now have a working mod_perl 1.99!
At 15:08 15/01/2003 +0100, Jérôme Augé wrote:
>To compile mod_perl-1.99_xx on RedHat 8.0 I used :
>
>$ perl Makefile.PL MP_APXS=/usr/sbin/apxs
>
>First, I removed the original mod_perl-1.99_05 RPMS then I compiled and
>installed the newer one.
Many thanks Jérôme, also Stas, and Paul for the advice on ditching the
RPM's :o)
Re[2]: Newbie advice required [some further info]
Posted by Seldo <ne...@seldo.com>.
On 06 February 2003, Stas Bekman wrote:
SB> Have you configured your server to run .php files by php?
>From httpd.conf: AddType application/x-httpd-php .php
(which is a yes as far as I'm concerned, but taking no chances...)
SB> Does a request to /bob.php works fine if requested directly (when
SB> you don't have your PerlTransHandler installed?
Yep, it works fine.
SB> Does it work for other handlers? e.g.:
$r->>uri("/perl/bob.pl");
SB> assuming that you have /perl configured to run ModPerl::Registry?
Hmm, that was illuminating -- that works fine too! And PHP is indeed a
filter in 2.0, as you say (unlike perl). So the problem is either
PHP-specific, or a problem with filters... gah. I'm going to bed now,
but at least I have a new line of attack to try in the morning.
Seldo.
____________________________________________
Seldo Voss: www.seldo.com
ICQ #1172379 or me@seldo.com
--------------------------------------------
Bart's Blackboard: "I will not strut around like I own the place."
Re: Newbie advice required [some further info]
Posted by Stas Bekman <st...@stason.org>.
Seldo wrote:
> I mentioned that I don't think there's a way to practically supply
> arbitrary data to Apache that looks like its coming from the
> filesystem. The other way I thought of is this:
>
> $r->uri() can map one URI to another. This means that a request to
> www.mydomain.com/app1/site/page.php
> could be remapped by my module to call app1.exe "/site/page.php" (i.e.
> using the remainder of the path as a parameter to determine what data
> to supply. This works, but it means extension-based handlers like PHP
> probably won't be activated -- how can I get around that, short of
> manually coding support for every requested file type?
Have you configured your server to run .php files by php?
> Also, the following code used as a PerlTransHandler sends the server
> into what looks like an endless loop:
>
> ----
> package Seldo::MaskURI;
> use strict;
> use warnings;
> use Apache::RequestRec ();
> use Apache::Const -compile => qw(DECLINED);
>
> sub handler {
> my $r = shift;
> $r->uri("/bob.php");
>
> return Apache::DECLINED;
> }
> 1;
> ----
>
> The code is supposed to perform the (nonsensical) task of returning
> "bob.php" no matter what URL the server is given. If ".php" is changed
> to ".html" it works, but as I say, having it as .php throws it for
> six. Anybody know why? It's possible there's something really obvious
> wrong -- like I said, I barely know perl, far less mod_perl.
Does it work for other handlers? e.g.:
$r->uri("/perl/bob.pl");
assuming that you have /perl configured to run ModPerl::Registry?
Does a request to /bob.php works fine if requested directly (when you don't
have your PerlTransHandler installed?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re[3]: Newbie advice required [some further info]
Posted by Seldo <ne...@seldo.com>.
I mentioned that I don't think there's a way to practically supply
arbitrary data to Apache that looks like its coming from the
filesystem. The other way I thought of is this:
$r->uri() can map one URI to another. This means that a request to
www.mydomain.com/app1/site/page.php
could be remapped by my module to call app1.exe "/site/page.php" (i.e.
using the remainder of the path as a parameter to determine what data
to supply. This works, but it means extension-based handlers like PHP
probably won't be activated -- how can I get around that, short of
manually coding support for every requested file type?
Also, the following code used as a PerlTransHandler sends the server
into what looks like an endless loop:
----
package Seldo::MaskURI;
use strict;
use warnings;
use Apache::RequestRec ();
use Apache::Const -compile => qw(DECLINED);
sub handler {
my $r = shift;
$r->uri("/bob.php");
return Apache::DECLINED;
}
1;
----
The code is supposed to perform the (nonsensical) task of returning
"bob.php" no matter what URL the server is given. If ".php" is changed
to ".html" it works, but as I say, having it as .php throws it for
six. Anybody know why? It's possible there's something really obvious
wrong -- like I said, I barely know perl, far less mod_perl.
Seldo.
____________________________________________
Seldo Voss: www.seldo.com
ICQ #1172379 or me@seldo.com
--------------------------------------------
My friend drowned in a bowl of muesli. He was pulled in by a strong currant.
Re: Newbie advice required
Posted by Honza Pazdziora <ad...@informatics.muni.cz>.
On Wed, Feb 05, 2003 at 11:45:09PM +0000, Seldo wrote:
>
> Ideally, it would be the former. Literally, I want all the files the
> users to come from one or another of a set of applications. The
> applications will return data in response to a URL: that data might
> be flat HTML, it might be PHP, or for some URLs it might be binary
> data. I don't want it to matter: I want the server to handle the
> content *as if it had just come from the filesystem*.
Well, if the data returned do not change as wildly, you might as well
get the output from other application and store it in the filesystem
cache. And then jsut work with ordinary files. Might also give you
some performance boost. Of course, if every request (for the same URI)
gives different result, this approach might not be as prctical, YMMV.
To be honest, I also would be very interested in knowing, if 2.0 can
handle all data sources transparently ...
--
------------------------------------------------------------------------
Honza Pazdziora | adelton@fi.muni.cz | http://www.fi.muni.cz/~adelton/
... all of these signs saying sorry but we're closed ...
------------------------------------------------------------------------
Re: Newbie advice required
Posted by Stas Bekman <st...@stason.org>.
Seldo wrote:
> Whoa, quick turnaround! Oof course, it's 11pm here, but only 6pm where
> you are I suppose...
It's actually 11am, on your tomorrow (PDT+11) ;) I'm living in the future ;)
> On 05 February 2003, Stas Bekman wrote:
> SB> You forgot to add to unfortunate facts that both mod_perl 2.0 and
> SB> Apache 2.0 are new and may have bugs ;)
>
>>>From what I could tell, doing this with Apache 1.3 is even more
> daunting, since it didn't really have the concept of filters ironed
> out.
True.
[...]
> SB> Assuming that you have a set of filters which do the work, it's
> SB> easy. e.g. I think php in 2.0 is an output filter, so you should
> SB> just dynamically insert the php filter when you figure out that
> SB> the content is php. HTML/text is easy. SSI is a filter, so covered
> SB> too. What other processors do you need?
>
> That's the thing. This application has to be flexible: I don't want to
> have to explicitly support file types; I simply want to supply the
> server with data that looks like a file and have it treat that data
> exactly as it would any other file.
The simplest way would be to save the extracted data into a file, and set
$r->filename to point to that file, and let the Apache core handle that. If
you want it to be smarter, but more complex, read on.
> However, I have a feeling this might be impractical, so alternate
> suggestions are welcome :-) At this point I feel I should be doing
> some kind of I-am-a-clueless-newbie dance. I am totally out of my
> depth, and this project is due in 3 weeks! *bursts into semi-panicked
> laughter*. Um. Yeah :-)
Well, we are all new to this thing so *you* are the one who has to be the
inventor.
In short, if all possible applications can be invoked as filters you should be
all set.
text/html: just send it out
text/plain: ditto
mod_perl: compile the handler (assuming that the code is coming from the db)
and configure the handler to be modperl/perl-script or set the
PerlResponseHandler to the one you've just compiled
exe: save the data in a file, and set $r->filename to it. Apache will do the rest.
php: though I haven't tried it, the php filter probably accepts its code as an
input to a filter. you have to check that though.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re[2]: Newbie advice required
Posted by Seldo <ne...@seldo.com>.
Whoa, quick turnaround! Oof course, it's 11pm here, but only 6pm where
you are I suppose...
On 05 February 2003, Stas Bekman wrote:
SB> You forgot to add to unfortunate facts that both mod_perl 2.0 and
SB> Apache 2.0 are new and may have bugs ;)
>From what I could tell, doing this with Apache 1.3 is even more
daunting, since it didn't really have the concept of filters ironed
out.
>> I want app1.exe (or whatever) to retrieve a file / run a database
>> query / do some processing and return some output.
SB> Do you say that the actual code resides in the database? So you
SB> want to fool Apache as if the code existed on the filesystem? Or
SB> does your database returns paths to the real files?
Well... to be honest, whichever is easier. I'm not that far along :-)
Ideally, it would be the former. Literally, I want all the files the
users to come from one or another of a set of applications. The
applications will return data in response to a URL: that data might
be flat HTML, it might be PHP, or for some URLs it might be binary
data. I don't want it to matter: I want the server to handle the
content *as if it had just come from the filesystem*.
SB> You mean PerlTransHandler, right? You are on the right track then.
Yes, I mean PerlTransHandler. Yay! Not completely bonkers then...
>> 2. Why would setting $r->uri() to a .php file be any different to
>> the rest of the server than setting it to a .html file?
SB> If you don't have a real file with the content you probably need
SB> to rely on output filters.
>> 3. How to ensure that the server treats the output of an
>> application the same as it does a file, i.e. applying all the
>> necessary handlers etc?
SB> Assuming that you have a set of filters which do the work, it's
SB> easy. e.g. I think php in 2.0 is an output filter, so you should
SB> just dynamically insert the php filter when you figure out that
SB> the content is php. HTML/text is easy. SSI is a filter, so covered
SB> too. What other processors do you need?
That's the thing. This application has to be flexible: I don't want to
have to explicitly support file types; I simply want to supply the
server with data that looks like a file and have it treat that data
exactly as it would any other file.
However, I have a feeling this might be impractical, so alternate
suggestions are welcome :-) At this point I feel I should be doing
some kind of I-am-a-clueless-newbie dance. I am totally out of my
depth, and this project is due in 3 weeks! *bursts into semi-panicked
laughter*. Um. Yeah :-)
Thanks again!
Seldo.
____________________________________________
Seldo Voss: www.seldo.com
ICQ #1172379 or me@seldo.com
--------------------------------------------
If idiots could fly, IRC servers would be airports.
Re: Newbie advice required
Posted by Stas Bekman <st...@stason.org>.
Seldo wrote:
> Hello everyone -
>
> I'm in the unfortunate position of being needing to write an Apache
> 2.0 module using mod_perl 2.0, while being simultaneously new to both
> mod_perl, the Apache API, and perl itself. I guess I'm a glutton for
> punishment, or something. (Did I mention this is all on Win32?)
You forgot to add to unfortunate facts that both mod_perl 2.0 and Apache 2.0
are new and may have bugs ;) But on the other hand you are the fortunate one
to be one of the first to embrace the new platform. What doesn't kill you
makes you stronger ;)
> What I want my module to be able to do is to substitute content from
> various plug-in applications as the response to various URLs. For
> example, if the user requests
> www.mydomain.com/app1/file
> I want app1.exe (or whatever) to retrieve a file / run a database
> query / do some processing and return some output.
Do you say that the actual code resides in the database? So you want to fool
Apache as if the code existed on the filesystem? Or does your database returns
paths to the real files?
> Importantly, I
> *then* want the rest of Apache to treat this file as if it had come
> from the file system, e.g. it it's a .php file I still want PHP to
> handle it, if there are any other handlers assigned I still want them
> to handle it. In short, this substitution has to be completely
> transparent. (This should be possible by returning Apache::DECLINED,
> but it doesn't seem to work like that, see below)
>
> Now, I know it's possible to configure Apache with app1.exe as a
> handler for /app1, etc.. What I'm creating is a single module that
> handles *all* URLs (i.e. handles "/"), and manages the mapping itself.
>
> So far, I think the best way to do this is to create a URI translation
> handler module which will simply use $r->uri() to call the application
> with whatever data and parameters it needs.
You mean PerlTransHandler, right? You are on the right track then.
> First question:
>
> 1. Is this really the best way to supply the server with content that
> comes from elsewhere than simply the file system?
>
> I've written a simple translator which can return .html files, but if
> I set the uri to a .php file the server seems to go into a loop (I've
> been unable to diagnose what's actually happening).
>
> 2. Why would setting $r->uri() to a .php file be any different to the
> rest of the server than setting it to a .html file?
>
> and finally
If you don't have a real file with the content you probably need to rely on
output filters.
> 3. How to ensure that the server treats the output of an application
> the same as it does a file, i.e. applying all the necessary handlers
> etc?
Assuming that you have a set of filters which do the work, it's easy. e.g. I
think php in 2.0 is an output filter, so you should just dynamically insert
the php filter when you figure out that the content is php. HTML/text is easy.
SSI is a filter, so covered too. What other processors do you need?
> Any and all advice appreciated, including "You fool! This already
> exists!" :-)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Newbie advice required
Posted by Seldo <ne...@seldo.com>.
Hello everyone -
I'm in the unfortunate position of being needing to write an Apache
2.0 module using mod_perl 2.0, while being simultaneously new to both
mod_perl, the Apache API, and perl itself. I guess I'm a glutton for
punishment, or something. (Did I mention this is all on Win32?)
What I want my module to be able to do is to substitute content from
various plug-in applications as the response to various URLs. For
example, if the user requests
www.mydomain.com/app1/file
I want app1.exe (or whatever) to retrieve a file / run a database
query / do some processing and return some output. Importantly, I
*then* want the rest of Apache to treat this file as if it had come
from the file system, e.g. it it's a .php file I still want PHP to
handle it, if there are any other handlers assigned I still want them
to handle it. In short, this substitution has to be completely
transparent. (This should be possible by returning Apache::DECLINED,
but it doesn't seem to work like that, see below)
Now, I know it's possible to configure Apache with app1.exe as a
handler for /app1, etc.. What I'm creating is a single module that
handles *all* URLs (i.e. handles "/"), and manages the mapping itself.
So far, I think the best way to do this is to create a URI translation
handler module which will simply use $r->uri() to call the application
with whatever data and parameters it needs. First question:
1. Is this really the best way to supply the server with content that
comes from elsewhere than simply the file system?
I've written a simple translator which can return .html files, but if
I set the uri to a .php file the server seems to go into a loop (I've
been unable to diagnose what's actually happening).
2. Why would setting $r->uri() to a .php file be any different to the
rest of the server than setting it to a .html file?
and finally
3. How to ensure that the server treats the output of an application
the same as it does a file, i.e. applying all the necessary handlers
etc?
Any and all advice appreciated, including "You fool! This already
exists!" :-)
Seldo.
____________________________________________
Seldo Voss: www.seldo.com
ICQ #1172379 or me@seldo.com
--------------------------------------------
To know the road ahead, ask those coming back.