RE: Apache config for compiled modules

> -----Original Message-----
> From: David Hakim [mailto:dhakim-Gkm/TONP9n1Wk0Htik3J/[email protected]] 
> Sent: Friday, February 21, 2003 4:47 PM
> To: Shay Harding
> Cc: Moto Devel
> Subject: Re: [moto-devel] Apache config for compiled modules
> 
> On Monday, February 17, 2003, at 05:15  PM, Shay Harding wrote:
> 
> > I've been messing with how the compiled modules work and 
> was wondering
> > if
> > this sounds like a good idea or not:
> >
> > Right now all modules act as Apache content-handlers. They cannot
> > intercept
> > requests as they fire at basically the end of the Apache 
> life-cycle. 
> > I'd
> > like to see this change to where you can specify, via httpd.conf, 
> > where the
> > module appears in the Apache handlers (i.e. access, authentication,
> > url-rewriting, content, etc).
> >
> Don't different stages of the apache life cycle have different inputs 
> and outputs ? I'm not sure if an embedded language like moto 
> is really 
> well suited for url-rewriting or authentication. Where does 
> the output 
> go ?

The only stage that truly performs output is the content handler (current
default for moto now). If I write an access handler module in Moto (which I
already have) I can then, via Apache access handler phase, return
"FORBIDDEN" and Apache will handle it from there and return a "401" (or is
it 403?) error page. If everything went well I return "OK" and Apache keeps
on processing.

> > The following config is an idea to begin to accomplish this:
> >
> > XXX = compiled module name
> >
> > <XXXLocation /myloc>
> > 	SharedHeapSize    32M
> > 	Session.Disable	TRUE
> > 	MotoAccessHandler	xxx
> > </XXXLocation>
> >
> >
> This is interesting. If there are two compiled modules would both of 
> them see the Session.Disable directive ? Is it a true apache 
> directive 
> in this case ? Would config options need to be registered somewhere 
> special like apache directives need to be ?

The only directive is "<XXXLocation ...>". The moto module registers to
handle this directive. Apache actually never sees anything past that since
the directive is specified as "<XXXLocation" so it eats it all until the
module itself breaks when it sees "</XXXLocation>".

Then in the "setOption" function we pull out each line inside the directive
and process it using the same "ap_" functions Apache uses to process
httpd.conf.

I already have the above working in my moto devel local directory. The
"Location" is still set using the value of "<XXXLocation>" as it currently
is doing.

> > This can appear in any <Location> or <Directory> tags if needed:
> >
> > <Location /mymainloc>
> >     <XXXLocation /myloc>
> > 		SharedHeapSize    32M
> > 		Session.Disable	TRUE
> > 		MotoAccessHandler	xxx
> >     </XXXLocation>
> >
> >     SetHandler someotheraccesshandler
> > </Location>
> >
> >
> > This would allow to do whatever Apache processing you needed for 
> > "/mymainloc" and for "/mymainloc/myloc" a Moto handler is 
> processed. 
> > The above config setup is two-fold: 1) it gets rid of "MotoOption
> > Location", 2)
> > gets rid of the syntax "MotoOption ActualOption Value" and 
> 3) can be 
> > used
> > like Apache's "<Location>" OR "<Directory>" tags:
> >
> > <MotoLocation /var/tmp>
> >
> > --OR--
> >
> > <MotoLocation /my/uri>
> >
> > By using the Apache API internal function ap_is_directory() we can 
> > tell which is being used.
> >
> Is SetHandler implicit with this syntax ?


SetHandler would appear outside the "<XXXLocation>" tags either enclosed in
"<Location>" or "<Directory>" tags or as a server global. Whatever the
module doesn't handle it will simply return "DECLINED" for and Apache will
skip it.


<Location /myloc>
   SetHandler mymodule

   <XXXLocation /mysubloc>
       ...
   </XXXLocation>
</Location>


> 
> >
> > How to get the compiled code to produce the correct handler 
> functions
> > is
> > still undecided as it seems to need options in mmc to tell 
> it how to 
> > produce
> > the compiled code. Like:
> >
> > mmc --handler access ...
> > mmc --handler content ...
> > etc
> >
> yeah ... that would be kindof a hairball ... also the 
> interpreter would 
> need to be changed as well so handlers could be tested.

The interpreted version would be more complex and basically a lot like
mod_perl which creates a Perl interpreter to parse the modules. The
"executeTemplate()" function seemed to be doing something similar here.

 
> I'm not convinced about the whole stage handler thing. It 
> sounds really 
> hard :) and I'm not sure moto is the right tool for the job 
> (although I 
> have no doubt it could be forced to perform it :) ). The block style 
> syntax is really interesting though. I'd like to hear more about that!
> 
> -Dave


I think the compiled moto modules are the exact tool for the job as they are
basically C Apache modules just as if you'd write them in C. Interpreted
Apache modules really don't need to be added except to parallel mod_perl
which is used a lot. It's so easy to take the moto files and compile them
that the *need* for interpreted ones is lessened. The *need* for mod_perl is
evident since you really can't compile Perl code (well you can but it's not
really good code :)).



Shay

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.455 / Virus Database: 255 - Release Date: 2/13/2003