You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Seldo <ne...@seldo.com> on 2003/02/06 00:45:09 UTC
Re[2]: Newbie advice required
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 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[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 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