Kurt McKee wrote:
Hello,
I disagree that adding a "Requests" directive would solve the problems
you've described. I see that there could be some benefit, but it seems
to me that a consistent precedence scheme for Handlers would be more
sensible. For instance, you wrote:
# Example 2:
#
Request "/trackback/.+php" {
Handler redir {
Rewrite "/(.+)\.php$" "/index.php?tb=1&name=$1"
}
}
It appears to me that, in this case, the functionality of the redir
Handler has been abstracted up into a Request in order to have
precedence over existing Directory and Extension directives. Further,
every Rewrite has to be nested in both a Request and a Handler, and the
regular expressions have to be crafted for both the Request and the
Rewrite.
Why? If the redir doesn't need the added functionality of the Request,
then there is no need for it to be in a Request block. Additionaly, I
would think that Request sections should be fairly specific, and if they
aren't then the administrator probably knows what he's doing.
I could be wrong, but I don't think Alvaro is proposing to elimiate the
current way redirs work, rather just add functionality.
This seems fairly analogous to the <Location> and <LocationMatch>
directives in apache. They doen't actually correspond to a physical
directory, just a part of the URL, and they act as a container for other
directives, such as rewrite, etc.
<snip>
Requests could very well be placed at the top of the list. However, I
think that Extension and Directory will lead to conflicts. For instance,
Python scripts may end with .py, and be used for the application
backend. However, source code may be available in certain download
directories. The Directory statement says "handle /src with the file
handler" while the Extension statement says "treat all .py files as cgi
scripts".
It would seem to be that this would be resolved if Extentions could be
localized, ie, in sepecific Directory statements. Or overridden in
specific Directory statements would work too. I am not familiar with
the code to tell whether or not that is a bad idea or not.
-John
_______________________________________________
Cherokee mailing list
[email protected]
http://www.alobbs.com/cgi-bin/mailman/listinfo/cherokee
