I don't think this can be done using Mod Rewrite but I will be VERY happy to be proven wrong, so want to throw this out for peer thought and review

Is it possible, via a mod_rewrite declaration (httpd.conf and/or .htaccess) for all URLs to be accessed and if they URLs refer to a server side language to be ,whether that be

PHP

 , a CGI (of whatever flavour) or SSI etc., "run", then prior to sending the output to the browser the content will be passed to a script for further processing?

This is the complete backwards way to normally using mod_rewrite. Usually you will intercept a URI call and then do whatever you want with it, whereas I want the server to do what it normally does, but then send the output to my script to be further "worked upon"

So am I wrong? Can you do the above ?


.
.
.
.

As I am typing I have thought of one way it can be done (sort of) but it is bloody ugly

Pass all requests to my script as per normal mod rewrite, then grab the file that would "normally be requested" and parse it for tell tale server side language functions.



are all tell tail signs of a

PHP

  script, meaning we know to run the code on the page via the

PHP

  interpretor, prior to manipulating the output.



Is a tell tail sign of a CGI script (using the shebang line to tell us the interpretor)

and



is an identifier of an SSI call

but compiling a list of every serverside language and how to test for each, and how to not fish up existing mod_rewrite directives is really starting to screw with my lil head. Is it the only way or is there a more elegant way it can be managed ?

Thanks

Jason

JD - are you saying that you want <whatever should normally happen to a page> to happen first, and *then* get your hands on it?

If so, may I suggest another method: it is a mod_rewrite and a double bake process. Consider this mechanism:

Prerequisite 1: the "actual site" needs to be running somewhere OTHER than off the primary domain... ie., it could be on the same domain but a different port, or another address or something. I'll use port 81 as an example because it's easy.

Apache

 :
* All non-graphics calls to theDomain are mod_rewritten into a single

PHP

  script. The virtualhost directive for <the target domain> is completely managed by your one primary script. There are examples of that rewrite all over the board, but ping if you need them again.
* The

PHP

  script calls for the same page, exactly as it saw it come in, on 127.0.0.1:81 instead of 80. Normal processing of the script takes place, regardless of language or plugin or whatever.
* The output from the port 81 call is returned to the

PHP

  call, which then can process the outputted HTML in anyway it sees fit...
* then the echo from the

PHP

  spits the double-baked HTML back out to the user.

I think that would do it...

/p

Perk that would definately do it but what I neglected to say was these aren't my sites and so no chance at you suggestion.

hmmmm... yet you have .htaccess to them? Curiouser and curiouser... because if you can get into the .htaccess to add something to the processing of the request, then you could add something to divert and process as I discussed above... or perhaps I'm just really missing something.

The only other way I know of is to hook the processing chain of

Apache

 ... I have only read of it in the abstract and it is not trivial. Essentially there are five (I think I remember that) points along the processing chain where you can jump in and "do something." I believe that the normal HTML construction is step 3. Obviously, if you can hook in later then you can do what you want, but I have no idea how tough that is. As I remember though, it was a shared object that you referenced in

Apache

 , meaning that it would have to be C[++]ish and compiled for <that> system. Yuck, really.

Cheers Perk.

I suppose I should explain but these are all other peoples websites, but they choose to work within a co operative

net

 work.

Because there will be a variety of sites in there and the mix of types of sites will be huge balanced with the mix of knowledge being larger still I believe that asking for an .htaccess file to be uploaded along with a script (which I can automate for them) will be manageable and also the limit of the access I can get.

I think that I will probably have to go the route I mentioned in the 1st post and parse the content of each file, looking for identifiers of language and then run the code through the respective interpretor.

To start with I believe that plain html and

PHP

  will be more than enough, working on the basis (to start) this is a nix / AP (from lAmP) solution.

Thanks for the assistance on the thought processes mate

What creeps me out about what you are saying is that *you* will be responsible to parse and execute against lots of other typs of coders... the opportunity for you to screw up and miss something is huge. Better, IMO, to let

Apache

  do its work and then jump in.

Have you looked at the

Apache

  directive AddOutputFilter? That series (AddOutputFilter, RemoveOutputFilter, SetOutputFilter) are the newfangled

Apache

  2+ ways of hooking the server post-HTML construction... it doesn't look as bad as I had initially thought. Essentially, if I read that stuff right, it'll allow you to do what you initially asked ie., a 2 process Virtual Host. There is also an AddInputFilter series, although that makes no sense here.

The example at the

apache

  docs is to do a DEFLATE on HTML after it's been processed with SSIs... I think this is probably close to where you want to go. There is a lot of discussion about such things - start here:

http://httpd.

apache

 .org/docs/2.0/filter.html

... then google

Apache

  Output Filters and you'll see a lot of discussion about how people are doing similar things. Although I have not found a spec on it yet, I'll bet the method of communication is simple pipes, stdin/out or TCP/IP... I'll bet it's not that difficult and could probably be written in a language of choice. But I have no proof of this yet.

Hope that bumps you in the right direction,
/p