Re: [PHP4BETA] Re: [PHP3] Re: [PHP4BETA] Writing Apache modules in PHP
| From: | svanegmond at bang dot dhs dot org | Date: | Sun, 12 Mar 2000 20:30:52 +0000 |
| Subject: | Re: [PHP4BETA] Re: [PHP3] Re: [PHP4BETA] Writing Apache modules in PHP | ||
| References: | 1 2 | Groups: | php.version4 |
| Request: | Send a blank email to php-version4+get-11980@lists.php.net to get a copy of this message | ||
Evan Klinger (evan715@sirius.com) wrote:
> Does anyone know how Perl (mod_perl?) does it? Are the modules written
> in Perl and then compiled into the server somehow?
> --
I'm surprised this is not widely known.
From perl.apache.org:
# With mod_perl it is possible to write Apache modules entirely in Perl.
Perl gives you access to most of the Apache API:
http://www.apache.org/docs/misc/API.html
# Apache breaks down request handling into a series of steps, more or
# less the same way the Netscape
# server API does (although this API has a few more stages than NetSite
# does, as hooks for stuff I
# thought might be useful in the future). These are:
#
# URI -> Filename translation
# Auth ID checking [is the user who they say they are?]
# Auth access checking [is the user authorized here?]
# Access checking other than auth
# Determining MIME type of the object requested
# `Fixups' --- there aren't any of these yet, but the phase is intended
# as a hook for possible extensions like SetEnv, which don't
# really fit well elsewhere.
# Actually sending a response back to the client.
# Logging the request
hese phases are handled by looking at each of a succession of modules,
looking to see if each of them
has a handler for the phase, and attempting invoking it if so. The
handler can typically do one of three
things:
# -Handle the request, and indicate that it has done so by returning the
# magic constant OK.
# -Decline to handle the request, by returning the magic integer constant
# DECLINED. In this case,
# the server behaves in all respects as if the handler simply hadn't been
# there.
# -Signal an error, by returning one of the HTTP error codes. This
# terminates normal handling of the
# request, although an ErrorDocument may be invoked to try to mop up, and
# it will be logged in
# any case.
This allows you to do such rocket science as having:
http://www.greedy.com/products/5432.html
... which will be indexed by a search engine, vs.
http://www.greedy.com/products.html?id=5432
... which probably will not. Of course, you want the former with the
file system efficiency of the latter. mod_perl can do it. The only way
I could conceive it right now in mod_php using a hack on the error
handler, but that's really about it.
Embperl (link on perl.apache.org) is quite a bit like mod_php, except
it's written in Perl, and wiggles its way into your pages via mod_perl.
Very clever, very cool. It's used on a site we produced like
http://www.gopuzzles.com/ . I'm a big fan of
PHP's simplicty, though.
I think Perl poses a much bigger maintenance problem because it is so
easy to write obfuscated code.
written in Perl, and does its thing
--
,,,
(. .)
+--ooO-(_)-Ooo------------ --- -- - - - -
| Stephen van Egmond http://bang.dhs.org/