On Saturday 13 June 2009 12:42:57 pm Daniel L. Miller wrote: > 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.
I take back the last part of what I said - after hand-editing the config file, leaving a complex non-final php handler w/ directory, plus a final directory after it, it seems to be doing exactly what I wanted. -- Daniel _______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
