On 05/01/2011, at 16:28, Matthew Haas wrote:
> On 01/05/2011 04:09 AM, Alvaro Lopez Ortega wrote:
>>> But as I said, from what I can tell, all rules seem to be falling through
>>> and hitting default. I would expect (again, I'm likely missing some
>>> fundamental understanding of cherokee rules) that if I'm trying to access
>>> main/, it hits the doku.php in the root (which I configured as an index)
>>> and should be happy with that rule...
>>>
>> - The first thing it does is to find the virtual server in charge of
>> processing the request. The request is evaluated against the virtual server
>> list from top to bottom (mind the order). As soon as a virtual server
>> matches, the evaluation stops.
> So am I correct in perceiving Cherokee's "virtual servers" as
> administrative/functional domains for web processing (and not necessarily
> separate web domains-- but could be)? That's the impression I got from the
> docs.
Yes, that's it. A virtual server can hold more than a single domain. Actually,
it holds a number of web resources. How you match requests to that virtual
server is a completely different business. The most normal thing is to check
the host, although there are other types of matches: IP of origin, protocol,
etc.
> And that's how I've been endeavoring to approach things- arranging as if they
> are one big if/else-if/else-if/else block... it checks each one, starting at
> the first, falling through to the second, the third, etc. and if none match,
> the final "else" (default) grabs it.
Yeah, 'default' is some sort of a safety net.
A non-final rule would be: if (match) { set props; }
A final rule would be: if (match) { set props; return; }
The default rule would be: { set props }
>> - Once the virtual server has been chosen, the request is evaluated against
>> the virtual server's behavior list. Again, the evaluation is perform in
>> order - from the top of the list to the bottom. Whenever a rule matches,
>> it's definitions are applied (authentication, handler, caching properties,
>> custom document root, etc). The evaluation stops when a 'Final' rule is
>> matched, or the 'default' rule (the last) is hit.
>>
> Okay... I'm trying to digest this... the behavioral rules are applied only
> AFTER a virtual server is identified... which means the identification
> criteria for virtual servers are based on:
>
> - Virtual Server nickname (is this just a label, or does it expect
> something real like a domain name?)
As I said, there are different matching mechanisms. It's up to you which to
use. The most common case is to use the wildcard matching (so you can
configure matches like: *.example.*), or regular expression matches (such us
.*\.example\.(com|org|net)), although there are others.
> - Document Root (if so, and I have both my dokuwiki site and default
> pointing to /var/www, wouldn't that match the dokuwiki site, as it is "above"
> default?)
> - Directory Indexes (I currently have default blank, and put in
> "index.php,doku.php" which are both present in the document root)
Those two are properties of a virtual host. They are applied as soon a virtual
host is matched.
The case of the document root is an exception though. You can overwrite it an
set a custom one from a behavior rule.
> - Can I assume "Host Match" will also aid in virtual server
> identification? So if I have "Match Nickname" set for the Host Match method,
> and I have Nickname set to "dokuwiki", which is currently just a label and
> bears no semblance of actual file structure on the disk... is that working
> against me?
>
> Does the Host Match criteria play a (or the?) fundamental role in virtual
> server identification? I'm going to try this of course, but just want to make
> sure I have an understanding of the selection criteria.
>
> And unlike the virtual servers, the behavioral rules can be cumulative...
> accruing attributes until an end-case (final or default) is reached... thanks
> for that clarification.
If none of the virtual server matching rules success, the virtual server nicks
are used on a second try. This is quite convenient when you are setting up a
server for testing, although it is not meant to be the default virtual server
mechanism.
For instance, if you name you virtual server "example", the server will match
request to http://example/ to that virtual server, as long as none of the
virtual server matching rules matched before.
>> - Then, the request is processed according with the parameter collected
>> during from the behavior rules.
>>
> To clarify, what precisely is this collected parameter? The URL requested, or
> the portion of the URL consisting of the path hanging off the document root?
> (based on my understanding, I'd assume at least the latter).
I meant, the configuration properties you set in the matched rules. There are
many properties that can be set, for instances:
- Handler: How the request is processed: static content, fastcgi, reverse
proxy, etc.
- Compression: gzip, deflate, any, ..
- Custom document root
- Bandwidth limitations
- Authentication: method, type, parameters
- etc, etc.
> I ask because you then go on to state:
>> Regarding the redirections/regular expression, it's important to notice that
>> they are match against the request rather than against the full URL. Bare
>> that in mind whenever you add regexs. Actually, since the virtual server
>> matching is performed in an early processing stage, it would not make much
>> sense to include in the request processing phase, would it?.
>>
> So I want to ascertain whether there is any operational difference between
> regex-specific rule processing and the information rules encounter in
> general...
>
> - Do rules receive JUST the "request" (path from docroot)?
Yes
>> I know it might be kind of uncomfortable to change the mindset to fit these
>> little differences at first. It is a much logical (and thus, natural) way to
>> define and maintain the behavior of a Web Server. It does only require a
>> while to forget the old habits and get used to it.
>>
> Oh, I'm not complaining... I *want* to use Cherokee because I am drawn to its
> structure... in fact it reminds me a bit of the structure of OpenBSD's pf
> firewall ruleset. I just need to pick up the intrinsics of the language
> (order of operations, data types, etc.)
Yeah, the follow is quite similar to a firewall.
Actually, it's kind of like two chained firewalls: the first matches the
virtual server, and that concrete virtual server contains a second one that
will define how the request is replied.
> Thanks for the information!
Sure. Cheers!
--
Octality
http://www.octality.com/
_______________________________________________
Cherokee mailing list
[email protected]
http://lists.octality.com/listinfo/cherokee
