httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Issac Goldstand <>
Subject Re: apache module or CGI (conclusion)
Date Tue, 27 Mar 2007 11:36:13 GMT
Sam Carleton wrote:
> Folks,
> I want to thank all three of you for your time, thoughts, and input on
> this matter.  I have reached a conclusion... Drum role please....  It
> will be....  a ....  apache module!!!!!!!!!!!
Excellent choice.
> In the end, it came down to portability.  I realize that either way I
> go, I need to be using APR and using apxs, it does appear that an
> apache module is actually easier to implement.  I got the skeleton up
> and running last night!
> On my nightly walk I started to think of the possibilities now that I
> am in the world that I know and love: C/C++.  I realized a way to
> implement the whole web solution in this module, but there are more
> infrastructure questions I have about how to tell the different
> "pages" apart.
> With the current PHP code, I have two different php pages:
> index.php:  It has two looks, one where it shows thumbnails, another
> where it shows one larger image.  Both pages have parameters passed to
> via the GET method.
> imageHandler.php: Given the correct parameters via a GET, it will
> downsize the image and send it out.
> My first question is, in an apache module, are there tools to get at
> the parameters passed to the module or will I still need something
> like cgic to get at them easily?

Absolutely.  Look at
It handles all standard get and post requests quite nicely.

> Second, right now the URL looks like
> I am using gets, I *THINK* I would like to change that so it simply
> looks like a path:
> Rather then the current:
> index.php?fldoid=f50b8377-d1cf-4407-bb59-a86ae7804d5c&imgoid=DSC_8912
> I would like to see something like this:
> index.php/f50b8377-d1cf-4407-bb59-a86ae7804d5c/DSC_8912
> I do recall seeing something, in years gone by, about how apache can
> do this type of thing and convert it back to a normal GET for the
> script.  With a module, do I lose this feature and have to simply
> parse it myself?
Nope.  You can use mod_rewrite to do this.  There are plenty of examples
in the online docs for mod_rewrite.  You can also do it yourself - see
> More importantly,  lets say my module is called mod_coolapp and when I
> have it installed, you get to it at /coolapp.  I want /coolapp to be
> the equivalent to the index.php and then have say, /coolapp/images be
> the same as imageHandler.php.  Is there any trick to knowing which
> "page" is being requested or is it simply a matter of doing a string
> compare to see if the first part of the string passed the actual URL
> (/coolapp/) is images?
You're going to want to parse/compare the string.  The "Right Way(tm)"
to do this would probably be during the translate_name or possibly
map_to_storage hooks to separate the URI mapping logic from the actual
response processing logic.

> Oh, one final question.  I am going to set things up so my customers
> have great flexibility in what the web page actually looks like.  The
> module will read in a template file to get what the out side, HTML
> wrapper is and then will call different XSLT scripts to actual
> transform the XML the module creates into HTML.  Is there any
> standards as to where these resource files should be located?
Not as far as I know.


View raw message