On 3/16/07, Igor Sysoev <is-G...@public.gmane.org> wrote:

Ok by me. Another option occurred to me, which might be clearer and is certainly more powerful: use set operators. Also, isn't the method available in a variable? So, e.g.

$method memberof {POST...} { ... } $method not memberof {GET} {...}

Of course you could pick a different keyword (eltof, etc). I would avoid "in" to avoid a collision with the sense of "inwardly directed". You could do something like %member, too.

The nice thing about this is that it removes a directive and relies only on syntax. The directive name doesn't actually do any work, after all. And with a set membership test you have a more general capability. Then it's just a predicate test, and you can support any predicate you like:

$UA memberof {IE SAFARI...} {...}

The semantics can be inferred directly from the syntax: no need for a directive.

Actually, now that I think about it, there is a good reason not to omit the operator (whether if be equality or membership). Something like

methods LOCK UNLOCK ...

can easily be misread to mean "here is a list of methods against which to test the request method." But that would imply that

methods != LOCK UNLOCK...

must mean "here's a list of methods _not_ to test the request method against". Logically this cannot imply that "methods" is everything else. The test is in fact a set membership test on the (one) request method against the method-list args. At least it looks that way to me. So both omission of an operator and use of the plural would be misleading.

In any case, this will be an improvement on limit_except. Now I can write the documentation. ;)

gregg