Re: Newbie advice required
On Wed, Feb 05, 2003 at 11:45:09PM +, 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 | [EMAIL PROTECTED] | http://www.fi.muni.cz/~adelton/ ... all of these signs saying sorry but we're closed ...
Re: Newbie advice required [some further info]
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 BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Newbie advice required
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 BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Newbie advice required
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 BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
