On Saturday 13 June 2009 03:56:30 am you wrote:
> On 13-jun-09, at 00:21, Daniel L. Miller wrote:
> >>> Also, because of this rule definition, it appears I've lost the
> >>> "index"
> >>> function.  If I specific a complete URL in the browser, well and
> >>> good -
> >>> but if I just specify the folder, it gets rejected.
> >>
> >> You can create another rule before this complex rule. It should be a
> >> "directory" with the same directory name that the complex rule, set
> >> document root according to that directory and set as non final.
> >
> > That doesn't work - and doesn't seem logical.  If we match from top
> > down, then if I have a simple directory match BEFORE the php match,
> > then
> > the php handler won't be executed.  And that seems to be how it works
> > for me.
>
> It depends on whether or not the rule was "Final". When a non-final
> rule is matched, the evaluation goes on until it either matches a
> Final rule or the 'Default' rule entry.
>
> That allows to refine setting by matching a number of rules. For
> instance, imagine an scenario where you want to set a special document
> root for the /downloads web directory. If the requested file exists,
> the file is sent, otherwise the server rewrites the request. It'd be
> configured in this way:
>
> - Dir. /download,            DRoot: /whatever,   Final: no
> - Dir. /download AND Exists, Handler: file,      Final: yes
> - Dir. /download,            Handler: redir,     Final: yes
>
> That's just an illustrative example. The basic idea is that non-final
> rules allow to apply partial configurations while the request is being
> matched against the rule list.
>

But this doesn't seem to match the way other setups are configured.  The 
default php handler is supposed to be BEFORE the directory rules, and checked 
as non-final.  To me, that logic suggests cherokee would have the following 
internal thought process upon receiving a request for 
"server.com/folder/file.php":

"Hmm...well, you're trying to talk to server.com.  I don't have any other 
virtual servers configured that match that, so I'll let my default server 
handle this request.  Now...you asked for a php file.  I'll scan down my 
default server rules...yes, I do find a handler for php files that is a simple 
match, so I'll use that.  It's also non-final, so I'll keep looking.  
Now.../folder is defined as a directory in a rule...let me look that up on 
disk...ok - looks like a valid request, I'll execute that php handler with 
your requested file and pass on the result to you.  And since the folder was 
defined as final, I'll stop looking for any other matches."

If the above does not match the server processing method, please correct me.

If however, it DOES - then I'm still trying to figure out how I can define a 
custom php handler for a particular directory.  If I just define a complex 
rule as a FastCGI handler with php extensions & the webfolder - then I have no 
simple rule for the directory only.  It would seem I should define the complex 
rule as non-final, so it will match a php request for that particular folder, 
and then have the folder rule after it defined as final.

But - that doesn't work, and doesn't match the advice I'm being given.
-- 
Daniel
_______________________________________________
Cherokee mailing list
[email protected]
http://lists.octality.com/listinfo/cherokee

Reply via email to